Implementing a service layer in an MVC architectur

2019-01-23 05:35发布

问题:

How would one typically implement a service layer in an MVC architecture? Is it one object that serves all requests to underlying business objects? Or is more like an object that serves different service objects that in their turn interact with business objects?

So:

  1. Controller -> Service -> getUserById(), or:

  2. Controller -> ServiceManager -> getUserService() -> getUserById()

Also, if the latter is more appropriate, would you configure this ServiceManager object in a bootstrap? In other words, register the different services that you will be needing for your app to the service manager in a bootstrap?

If none of the above is appropriate, what would help me get a better understanding of how a service layer should be implemented?

Thank you in advance.

回答1:

The way I read this question, there's really two things that should be answered:

A) I would prefer splitting "Service" into "CustomerService" and "OrderService", in other words grouped by domain concepts.

B) Secondly I'd use dependency injection to get the proper service directly where I need it, so I'm basically using alt 1. The added abstraction in alternative 2 provides no additional value for me, since the IoC container does the important part.



回答2:

Using a "facade" is one way to go:

"A facade is an object that provides a simplified interface to a larger body of code"



回答3:

I personally prefer #2, and yes, it would generally be configured in a bootstrap, or the dependencies would be resolved using some sort of IoC container to give you the actual concrete instances.

I would also like to comment, and yes I understand this is probably more of a personal preference. Try to avoid using the name "Service" layer for these objects. refer to them as repositories or something else. if you use service, that term becomes overloaded ... because then devs are like, "do you mean like, a rest or wcf service?". trust me, we did that with a recent project, and we confuse ourselves all the time when we're talking about where to make code changes :-P