Let's say I have a following repo pattern :
interface IGenericRepo<T> where T : class { IEnumerable<T> GetAll(); T GetById(object id); void Insert(T obj); void Update(T obj); void Delete(T obj); void Save(); } interface ICustRepo : IGenericRepo<Cust> { IEnumerable<Cust> GetBadCust(); IEnumerable<Cust> GetGoodCust(); } public class CustRepo : ICustRepo<Cust> { //implement method here }
then in my controller :
public class CustController { private ICustRepo _custRepo; public CustController(ICustRepo custRepo) { _custRepo = custRepo; } public ActionResult Index() { var model = _custRepo.GetAll(); return View(model); } public ActionResult BadCust() { var model = _custRepo.GetBadCust(); return View(model); } }
Basically my pattern is something like
View <-> Controller -> Repo -> EF -> SQL Server
but I saw a lot of people doing this
View <-> Controller -> Service -> Repo -> EF -> SQL Server
So my question is :
Why and when do I need service layer
? Isn't that just add another unnecessary layer because every non-generic method is already implemented in ICustRepo
?
Should the service layer return DTO
or my ViewModel
?
Should the service layer map 1:1 with my repo?
I've look around for few days but I haven't satisfied with the answers.
Any help will be appreciated and apologize for bad english.
Thank you.
UPDATE :
Difference between Repository and Service Layer?
I've already read this. I already know the difference between those 2, but I wanna know why and the purpose. So that doesn't answer my question
The service layer is there to provide logic to operate on the data sent to and from the DAO and the client. Very often these 2 pieces will be bundled together into the same module, and occasionally into the same code, but you'll still see them as distinct logical entities.
The service layer approach is appropriate if you have a complex architecture and require different interfaces to your DAO's and data. It's also good to provide course grained methods for clients to call - which call out to multiple DAO's to get data.
MVC (or Model-View-Controller) is an architectural pattern on which to build software. The basic idea in it is to separate internal data models from the user interface via the controller and view.
Model–view–controller (MVC) is a software architectural pattern commonly used for developing user interfaces that divide the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.
TL;DR
Explanation
The typical 3-layer architecture is composed of Presentation Layer, Service/Domain Layer, Data Access Layer (DAL).
Think of the Service layer as the "Core" of your Application. Typically, the Service Layer only has Repository Interfaces that will be implemented in the DAL.
Therefore it allows you to "easily" switch the way you access data. The objects returned by the service layer should not be DAO's, because after all, the Presentation Layer doesn't even "know" the DAL exists.
Scenario: You have a 3-tiered Solution. Currently doesn't make much sense in having all layers.
/-------------------\ | Web App | <--- Presentation Layer |-------------------| | Service Library | <--- Service Layer |-------------------| | Entity Framework | <--- Data Access \-------------------/
Now you want to have a REST API in ASP.NET MVC WebApi
/--------------------\ | Web App | REST API | <--- Presentation Layer |--------------------| | Service Library | <--- Service Layer |--------------------| | Entity Framework | <--- Data Access \--------------------/
Now, for example, you no longer want to use Entity Framework as your Data Access and want to use NHibernate.
/--------------------\ | Web App | REST API | <--- Presentation Layer |--------------------| | Service Library | <--- Service Layer |--------------------| | NHibernate | <--- Data Access \--------------------/
Notice that we added a new form of Presentation and switched the way we access Data, but the Service Layer never changed.
Typically, the Service Layer exposes Interfaces to be implemented in the Data Access Layer so we get the "abstraction" we want.
I implemented a project with this architecture in university. You can check out the code HERE
I hope this helped. Sorry if I'm so boring @ explaining things :P
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