3

I read a couple of articles and questions related to layered architecture in ASP.NET, however I got a bit confused after too much reading. The UI layer is developed in ASP.NET MVC and for the data access I use EF in my project.

I'd like to describe my problem through an example. Let's say I have a simple blog engine, with the following entities: Post, Comment, Category, User. I use EF database approach and generate POCO-s in my model layer to a data model class library, the generated datacontext and the EDMX goes to the data access library.

Above this I have a business layer. This is responsible for example to return a blog entry with comments. In my UI layer I'm using ViewModel classes because for displaying an entry I need both a Post entity and a list of Comments with usernames on the same view.

And now my problem: My view doesn't need every details of a User entity, just the name in order to display a post. The question is where should I do the mapping between my ViewModels and Model classes? Should the business layer do this? Or I should return the entities with every details and let the UI handle the mapping? Should the business layer contain ViewModels as a class library?

What is the best approach for this?

norbip
  • 625
  • 7
  • 21
  • Good question. It's a dilemma. People seem to like this approach. http://stackoverflow.com/questions/664205/viewmodel-best-practices/694179#694179 – Brett Oct 31 '11 at 09:45

2 Answers2

2

The question is where should I do the mapping between my ViewModels and Model classes?

Ideally in a separate mapping layer. If you use AutoMapper mappings could be declared in separate files in the ASP.NET MVC project.

Should the business layer do this?

Absolutely not. The business layer has no knowledge of any view models.

Should the business layer contain ViewModels as a class library?

No. The UI layer (ASP.NET MVC application) is the only layer that has knowledge of view models. They could of course be in a separate class library if you wish, but it is only the UI layer that should reference it. View models are tightly coupled to views. And views are part of the UI.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • So my business layer should return my model classes with every detail and do the mapping in the WebUI project? But aren't these model classes heavier than they should be? For example I only need one attribute from my User entity. Or should I introduce some new model classes (I've read some stuffs about DTOs, business entites.) for the tasks I need in my model layer or my business layer and return these to the UI? – norbip Oct 31 '11 at 09:46
  • @norbip, yes domain models could be heavier than view models. But that's what the business layer returns. If you use an ORM you could configure lazy loading for associations. Then since the mapping layer will use only some associations of those business models in order to construct the view model this won't be a problem. – Darin Dimitrov Oct 31 '11 at 09:51
  • Just one more question. What if my business layer queries the data layer with projection. Because of the projection I get anonymous types, but I want to return a typed object. This type might be different than the ones already exist in the model layer. In this case, the class should be defined in my business layer then? – norbip Oct 31 '11 at 12:14
  • 1
    @norbip, you should not return anonymous objects when performing projections. The class should be defined in the same layer that performs the projection in order to replace the anonymous object. So if you are performing the projection in the business layer then the model should be defined as a domain model in the business layer. – Darin Dimitrov Oct 31 '11 at 12:33
1

Hi I prefer using the ViewModel in UI layer. I read the book Pro ASP.NET MVC 3 Framework by Steven Sanderson. And in examples of this book, are a lot of ViewModels examples, I recomended read this book.

David Horák
  • 5,535
  • 10
  • 53
  • 77