0

I'm new to MVC. I come from Webforms, by the way I was also using Servicestack ormlite.

I need to know if I can have an MVC project, but the Model section can be in a different assembly, so I can share this assembly with other projects (console app, web api, mvc project).

It is important that the assembly can have the Model section using the servicestack functionality for model(s) definition(I use servicestack ormlite for data layer), so here comes my other question, that servicestack's model(s) definition can it be used for the "views" in the MVC project? ie, the models syntaxis for servicestack is compatible with the strong typed models in the views MVC?

do you have a sample of:

  • models in external assembly
  • share models definition for DAL in servicestack(ormlite), and working in the views for the MVC project

Thanks in advance.

iomega55
  • 21
  • 3

1 Answers1

1

OrmLite is very flexible and resilient in what clean POCOs you can use with it, from a previous answer:

Clean POCOs

The complex Data Models stored in OrmLite or Redis doesn't suffer from any of these issues which are able to use clean, disconnected POCOs. They're loosely-coupled, where only the "Shape" of the POCO is significant, i.e. moving projects and changing namespaces won't impact serialization, how it's stored in RDBMS tables, Redis data structures, Caching providers, etc. You're also not coupled to specific types, you can use a different type to insert data in OrmLite than what you use to read from it, nor does it need to be the "exact Shape", as OrmLite can populate a DTO with only a subset of the fields available in the underlying table. There's also no distinction between Table, View or Stored procedure, OrmLite will happily map any result-set into any matching fields on the specified POCO, ignoring others.

Effectively this means POCOs in ServiceStack are extremely resilient and interoperable, so you can happily re-use the same DTOs in OrmLite and vice-versa without issue. If the DTO and Data models only deviate slightly, you can hide them from being serialized or stored in OrmLite with the attributes below:

public class Poco
{
    [Ignore]
    public int IgnoreInOrmLite { get; set; }

    [IgnoreDataMember]
    public int IgnoreInSerialization { get; set; }
}

Otherwise when you need to separate them, e.g. more fields were added to the RDBMS table than you want to return, the DTO includes additional fields populated from alternative sources, or you just want your Services to project them differently. At that point (YAGNI) you can take a copy of the DTO and add it to your Services Implementation so they can grow separately, unimpeded by their different concerns. You can then effortlessly convert between them using ServiceStack's built-in Auto Mapping, e.g:

var dto = dbPoco.ConvertTo<Poco>();

The built-in Auto Mapping is also very tolerant and can co-erce properties with different types, e.g. to/from strings, different collection types, etc.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390