Menu
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).
903
The business logic should be placed in the model, and we should be aiming for fat models and skinny controllers. As a start point, we should start from the controller logic. For example: on update, your controller should direct your code to the method/service that delivers your changes to the model.
Business logic should live in the data model. And, what's more, it should live in the graph data model because that's the right abstraction for the next twenty years.
Data representation is done by the view component. It actually generates UI or user interface for the user. So at web applications when you think of the view component just think the Html/CSS part.
The Business Logic layer handles all of the business rules, calculations and actual logic within your application that makes it actually "do" things and it may often use some of the objects retrieved from your data-access layer.
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.
73
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
