3

In a project I am working on, I have 3 layers of domains.

MVC 5 App [Has Reference]-> Class Library [Has Reference]-> Data access layer (Entity Framework).

  • DAL has POCOs
  • Class Library Has DTOs
  • MVC App has ViewModels

For example, I have a very basic person class for each Layer, and I am using Auto Mapper map like;

CreateMap<POCO,DTO> //(in class library)
CreateMap<DTO,ViewModel> //(in MVC app)

Since this person class is very basic, all three layers has almost identical class definitions. As my project grows, there are more classes started have same structure on all layers. And I am mapping same class definitions from one to another.

There are some complex classes that makes sense to have 3 different definitions on each layer but classes like this "person" class makes me thing if this is a acceptable approach to define same class definitions on each layer.

I know this questions looks like candidate of a "broad topic" question, but I could not find clear definition or a blog post online. Since books are mostly focused on one of these layers, I could not find a compherensive coverage on this.

Shortly, even for basic entity classes, what would be to good approach for class definitions on each layer?

Teoman shipahi
  • 47,454
  • 15
  • 134
  • 158
  • if they are really POCOs then yes it might be a good idea to make those and the ones from the Class Library a cross-cutting concern IMO - for the ViewModels it's no - either you don't need a viewmodel at all because everything you need is on the model already or you have some additional information you should not share up to the business-logic - but **yes**: *this seems very opinion based* – Random Dev Jul 27 '15 at 04:42

2 Answers2

1

After some more research on this concept, I found very similar question asked before: How do I reduce duplication of domain/entity/DTO objects?

And this question leads me a great article; http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/

Basically, If I want clear separation between layers, some duplication and mapping between those is a price I need to pay, there is no such thing as a free lunch.

Otherwise, as @Maris says, I can choose the path of creating common persistence objects which will transfer over layers, it will reduce duplication and time spent on changes of related entity classes, however I may end up having irrelevant properties and attributes on my classes to keep support on all layers.

As a result I am tent to go with 1st path.

Community
  • 1
  • 1
Teoman shipahi
  • 47,454
  • 15
  • 134
  • 158
-1

The best approach in your case to create Common project and move all common classes to that project, so every of your three layers can access common classes. Common project should not know anything about your 3 layers.

But I don't think that having different viewModel/DTO/POCOs on each layer is the best approach.

I usually use the next architecture:

Data access layer(DAL) - have they POCOs which is mapped from DB(at the same time they are Domain models in case of DDD)

Business Layer(BL) - uses Domain models from DAL

Presentation Layer(PL) - getting Domain models from BL and maps them on their ViewModels and uses ViewModel for it presentation logic.

Maris
  • 4,608
  • 6
  • 39
  • 68