tags:

views:

1125

answers:

3

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  A: 

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

Joel Martinez
Joel, thank you for your response. I agree with your objection to naming it Service. I just picked up on that, but actually frowned upon it a little myself. But the concept of the layer appealed to me.I'm trying to grasp the whole concept of dependency injection also at this moment, but it's not entirely clear to me how this works. Could you give a brief example of how this would work in an MVC environment?I mean, where would you inject what in wich object if where talking about retreiving User objects for instance? I have a hard time grasping that concept. Thank you in advance.
fireeyedboy
trust me when I say that I understand when you say that you're trying to wrap your head around ioc. it took me a bit to figure out when/where to use it :-) this comment box is too small to really get into it, but I'd suggest checking out the ninject lib (http://ninject.org/). their tutorials go through step by step and start to introduce the concepts. to summarize, it's all about separating the API from the concrete implementation. your code in the mvc project should work against your API not your specific implementations .... that way you can change them later when unit testing
Joel Martinez
According to Martin Fowler, a service layer "defines an application's boundary with a layer of services that establishes a set of available operations" In line of biz apps these operations are usually CRUD, but not always. So I don't think service layer = repository. How a true service layer (which I love) fits into MVC is still a mystery to me. My gut feel is that the M in MVC should be replaced with an S. Unless the controllers form the service layer that I'm talking about? I guess that is how most people do it. But should the controllers define the application boundaries? I'm confused...
Kevin Thiart
There can be multiple boundaries. I think that's where you're getting confused. MVC should only concern itself with what that specific application needs to do. So one could see an architecture where the Model talks to a service layer (which could be CRUD as you mentioned).
Joel Martinez
+1  A: 

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.

krosenvold
Thank you for your response krosenvold. Concerning you answer:A) Understood and agreedB) I see what you are saying about the redundant abstraction. But as I have commented to Joel: I have a hard time grasping how IoC would be implemented in a MVC environment.Where would this take place? In the controller? How does this offer aditional value? I don't think I understand the principle of IoC too well to grasp it's benifits.Or are we talking about configuring it in a bootstrap as well?If you would like to elaborate (maybe with a brief example) I'ld appreciate it very much. Thanks.
fireeyedboy
The key concept to understand about dependency injection is that is that to be effective it will be used in *most* places. Typically you hook the IoC container in at a very low infrastructural level, and it just permeates through everywhere.
krosenvold