Where to put data manipulation and business logic code in ASP.NET MVC application?

Question

Having watched samples from Rob Conery's Kona application, I see that he is using two things with IoC - ISession, where he has data layer code and Services, where he has some additional business logic that we need to perform when manipulating data in datastore. For instance, we might not just add a record to the DB but also change properties of another record, increase some counts, take something back, etc. We need to put that additional code somewehere and he puts it in those services.

For instance, he has a CustomerService that manipulates Customers. This requires us to send ISession instance to the CustomerService, so that the CustomerService can use it to access the datastore.

Now another way of doing it would be to put that additional code in the Customer class itself and send the ISession (or IRepository, whatever terminology we use) to that class. And not have any services. Typically, Customer, Order, Product, etc. classes are Model classes, so that would result in big/heavy model classes.

My question is, which solution is better? So far I did not have the need for that because I had most of the code in the controllers but now as my application grows, I need to make a decision on this and cleanup the controllers.

Currently I have: - fat controllers with business logic in it, - very atomic repositories, - very clean models and viewmodels.

Should I move to: - slim controllers, - repositories with more code, - models with business logic code (specifically should my model classes contain methods like Add(), Remove(), for instance Customer.Remove()??)

or to - slim controllers, - atomic repositories, - still clean models, - services (to encapsulate everything else that does not go into any of the previous).

Answer 1

I would recommend you having repositories containing atomic operations with the model classes and service layer which depends on those repositories to define business operations. The concept of AOP could be used to automatically start a SQL transaction at the beginning of each business operation and commit at the end or rollback in case of exception.

Finally controllers will use those service classes and convert between the domain models and view models.