Last post Apr 18, 2014 09:35 AM by Illeris
Apr 15, 2014 11:51 PM|spdev101|LINK
If I am implementing the Unit Of Work and Repository Pattern for data access where should I implement the business logic. I am using ASP.NET MVC. Should it be in the Controller or should I introduce another layer inbetween the controller and unit of work?
Apr 16, 2014 03:17 AM|Mikesdotnetting|LINK
You should have a separate layer for business logic. It shouldn't be in the controller.
Apr 16, 2014 03:26 AM|spdev101|LINK
Is there any design pattern I should use for this or is this a straightfoward reading and passing of the values to the controller?
Apr 16, 2014 03:46 AM|Mikesdotnetting|LINK
It depends on the requirement of your application but you can simply call the business layer methods in your controller eg:
public ActionResult DoSomething(Model model)
The controller has no idea what the ApplySomeRule() method does. That means that if the logic in the rule needs to change at some point, the controller code doesn't. This is fairly basic separation of concerns. The business logic layer in an MVC app is part
of the "Model" (which shouldn't all be stuffed into one folder as the Visual Studio templates suggest). It can be a separate project altogether.
Apr 16, 2014 03:50 AM|spdev101|LINK
Thanks, should the data loading (throught the unit of work) happen by the controller or through the business logic layer?
Apr 16, 2014 04:04 AM|Mikesdotnetting|LINK
The examples here: http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application show
the unit of work being instantiated in the controller, which seems fine to me. In that respect, the UoW is part of the conceptual Business Logic Layer.
Apr 18, 2014 06:03 AM|Illeris|LINK
You have 3 layers in your app (as far as I interprete your questions):
The UOW resides in the DAL. The controller is part of the presentation layer. In good architectures : the controller invokes the BLL. The BLL invokes the DAL.
Apr 18, 2014 08:09 AM|Mikesdotnetting|LINK
The UOW resides in the DAL.
UOW doesn't perform data access - it coordinates it. In that respect, its part of the business logic of the app. Unit of Work knows nothing about how stuff is being persisted or where, which is the role of the DAL. If you changed your data access strategy
(say from a relational DB to XML), you shouldn't need to touch the UOW code.
Apr 18, 2014 09:35 AM|Illeris|LINK
That would be an interesting discussion : DAL or BLL :-)
It depends on how you implement the DAL and how you implement the UOW. It can reside in both. If you use the UoW to control different data stores, with multiple ORM frameworks (or a hybrid of ORM and custom repositories), I'd position it in the DAL. If you
use it do make the liason between a business transaction, or number of transactions, and all related information changes, you can position it in the BLL. It actually depends on interpretation and the complexity of your application.
In a basic scenario where you persist entities on tables, the UoW should not be applied at DAL level as it has no real meaning there. However : if entities are split and persisted in different stores, where each part has not meaning individueally (in the
sense of : you need it all to have something that makes sense)...