Mapping Entities to Models and Performing Business Logic in ASP.NET MVC

Question

What is the best practise in mapping your database entities to your models and performing business logic? I've seen considerably different implementations of both. I have noticed a number of implementations where the Repository(in the Data Layer) itself is responsible for mapping the database entities to the domain models. For example, a repository that would do this:

public IQueryable<Person> GetPersons()
{
      return DbSet.Select(s => new Person
                    {
                        Id = s.Id,
                        FirstName= s.FirstName,
                        Surname= s.Surname,
                        Location = s.Location,
                    });
}

But having searched comprehensively around SO on N Tier design, I've noticed that while there is no silver bullet, in most situations it's advisable to perform the mapping inside the controller in the MVC project either manually or using a Mapper. It's also been reiterated that the Service layer should never perform the mapping and that it's responsibility should be to perform business logic. A couple of questions here:

1. Which method is advisable in regards to where to map the entities to models and vice versa? Should the repository do this or should the mapping be done in the controller?
2. Suppose I want to perform some business logic on the entities that I have retrieved from the database, for example, return the full name of the Person enities, or increase the age of all Persons by 10 years, where should this operation be performed. On the model itself? For example would I have a FullName property on the model which would compute the full name and the age? Or do I define some service inside my service layer to perform business logic?

EDIT

Wow so many close votes. Apologies, I didn't search comprehensively enough. The 'where to perform business logic' issue I've raised here can already be found on SO and elsewhere (although conveyed somewhat cryptically at times):

Validating with a Service Layer by Stephen Walther

Skinny Controllers

Another great, but more generic answer here on SO

Where Should I put My Controller Business Logic in MVC

Does a Service Map Entities to a View Model

However I'm yet to find a standard solution to the mapping question I had, and I think I could have perhaps expressed my question more eloquently. So the general consensus seems to be that business logic goes in the service layer, and mapping the domain models to view models should take place in the controller/presentation layer. And since it's advisable not to surface your DB entities to any layers other than the Data layer, it's recommended to map your entities to domain models at the data layer either manually or via a mapper such as Auto Mapper (This is what I have gathered from reading many articles). My confusion arose from the question of where should mapping entities to domain models and mapping domain models to view models take place. However as I previously alluded to I could have expressed my question more clearly. The reason for my confusion was that I had read that mapping entities to to domain models should happen in the controller, this should rather be rephrased to say "Mapping entities to domain models should happen at the data later, and mapping domain models to view models should take place in the Controller.

Answer 1

1. Which method is advisable in regards to where to map the entities to models and vice versa? Should the repository do this or should the mapping be done in the controller?

I strongly prefer to see the mapping happen in the repository and not the controller. The controller needs to act purely as a coordinator as Suhas mentions in his answer. As an alternative, maybe you can utilize a mapping class in the repository that passes the entity and return a mapped model - kind of like Auto Mapper

2. Suppose I want to perform some business logic on the entities that I have retrieved from the database, for example, return the full name of the Person enities, or increase the age of all Persons by 10 years, where should this operation be performed. On the model itself? For example would I have a FullName property on the model which would compute the full name and the age? Or do I define some service inside my service layer to perform business logic?

If it's possible, perform the business logic on the service. Why put the burden on the application to do what the service layer should have done? I believe this is the service's domain, not the app's. Also, I don't think returning concatenated or derived properities from the model is a bad thing either.

Summary:

• Controller handles requests from views and forwards them to repository
• Repository is the conduit to your datastores
• Service handles requests from repository, processes business logic, and returns mapped models

Answer 2

I usually create a small service layer within the MVC project to handle the additional work that MVC layer needs to get done. So in your example, you can have a PersonService or a PersonHandler which calls into your business layer to get all the persons entities and then increase the age of all persons by 10 years (assuming this is not you business logic but just something that UI needs), concatenate first name and last name to build full name etc. Controller then just calls into this service and never knows what is going on behind the scenes. This way your controller is doing what it should ideally do - coordinate between view and model.

Answer 3

It depends... Like you said there is no a silver bullet. One can only list pros and cons of each approach but still it is you who knows your requirements better than anyone else here. If you have time I suggest reading this book Patterns of Enterprise Application Architecture. This will give you a good understanding about different business logic and data source architectural patterns, when and how to use them. What should go to business layer and what should go to DAL. Also the book addresses the issue of how to map from DAL to Domain entities. You may even change you mind and choose absolutely different approach in the long run.

Also consider using some ORM which provides you with a Code First mechanism like EF Code First or NHibernate. In this case all mapping logic will be transparent to you at all.

Answer 4

Data Access layer (repository) should only handle inserting/updating/retrieving your data entities. Your service layer handles business logic and is in charge of the communication between your presentation layer (controller, view models) and your data layer. This means that your conversion from data entities to domain should happen at this layer. Your presentation layer (controller) should handle the conversion between your view models and domain models. -If you want to have a better understanding, you should take Maksym's advice and pickup Patterns of Enterprise Application Architecture as I consider (and many others) consider Fowler as THE authority on web application development. Another good book is ASP.NET Design Patterns which is based off of Fowler's book but concentrates only on the ASP.NET Framework.