问题
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 inICustRepo
?Should the service layer return
DTO
or myViewModel
?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
回答1:
TL;DR
- See explanation below
- Layers above Service Layer should not be "aware" that more Layers exist below Service Layer.
- Not necessarily, because you can have for example Data from 1 Type scattered across 2 tables and the "Core" only see's one, the Data Access Layer is responsible for "Grouping" and returning the Service Layer Type
Explanation
The tipical 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. Tipically Service Layer only has Repository Interfaces that will be implemented in the DAL.
Therefor 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.
Tipically 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
回答2:
Ad.1 Service layer should be place for whole business logic. It's more about separate responsibilities:
Controller - responsible for prepare viewModel and pass to the specific view,
Repository - abstract layer responsible for gathering entities from DB
Service - responsible for complex logic. There is often case that service uses many entities to make some logic and return just DTO.
Ad.2 In my opinion service layer should return DTO objects which should be mapped to the viewModels in Controllers.
Ad.3 No this is not the case. In your example you can move GetBadCust and GetGoodCust from repo to the service and return some DTO
来源:https://stackoverflow.com/questions/31180816/mvc-design-pattern-service-layer-purpose