Should the services in my service layer live in separate projects/DLLs/assemblies?

Question

I have an ASP.NET MVC 3 application that I am currently working on. I am implementing a service layer, which contains the business logic, and which is utilized by the controllers. The services themselves utilize repositories for data access, and the repositories use entity framework to talk to the database.

So top to bottom is: Controller > Service Layer > Repository (each service layer depends on a single injectable repository) > Entity Framework > Single Database.

I am finding myself making items such as UserService, EventService, PaymentService, etc.

In the service layer, I'll have functions such as:

• ChargePaymentCard(int cardId, decimal amount) (part of PaymentService)
• ActivateEvent(int eventId) (part of EventService)
• SendValidationEmail(int userId) (part of UserService)

Also, as an example of a second place I am using this, I have another simple console application that runs as a scheduled task, which utilizes one of these services. There is also an upcoming second web application that will need to use multiple of these services.

Further, I would like to keep us open to splitting things up (such as our single database) and to moving to a service-oriented architecture down the road, and breaking some of these out into web services (conceivably even to be used by non-.NET apps some day). I've been keeping my eyes open for steps that might make make the leap to SOA less painful down the road.

I have started down the path of creating a separate assembly (DLL) for each service, but am wondering if I have started down the wrong path. I'm trying to be flexible and keep things loosely coupled, but is this path helping me any (towards SOA or in general), or just adding complexity? Should I instead by creating a single assembly/dll, containing my entire service layer, and use that single assembly wherever any services need to be used?

I'm not sure the implications of the path(s) I'm starting down, so any help on this would be appreciated!

Answer 1

It is better to separate the services from the consumers. In our peojects we have two levels of separation. We used to group all the service interfaces into one Visual Studio project. All the Service Implementations are grouped into another project. The consumer of the services needs to reference two dll but it makes the solution more maintainable and scalable. We can have multiple implementations of the services. For e.g. the service interface can define a contract for WebSearch in the interfaces project. And there can be multiple implementations of the WebSearch through different search service providers like Google search, Bing search, Yahoo search etc.

Answer 2

Having one DLL per service sounds like a bad idea. According to Microsoft, you'd want to have one large assembly over multiple smaller ones due to performance implications (from here via this post).

I would split your base or core services into a separate project and keep most (if not all) services in it. Depending on your needs you may have services that only make sense in the context of a web project or a console app and not anywhere else. Those services should not be part of the "core" service layer and should reside in their appropriate projects.

Answer 3

IMO - answer is it depends on a lot of factors of your application.

Assuming that you are building a non-trivial application (i.e. is not a college/hobby project to learn SOA):

• User Service / Event Service / Payment Service -- Create its own DLL & expose it as a WCF service if there are more than one applications using this service and if it is too much risk to share the DLL to different application
  -- These services should not have inter-dependencies between each other & should focus on their individual area
  -- Note: these services might share some common services like logging, authentication, data access etc.

• Create a Composition Service -- This service will do the composition of calls across all the other service
  -- For example: if you have an Order placed & the business flow is that Order Placed > Confirm User Exists (User Service) > Raise an OrderPlaced event (Event Service) > Confirm Payment (Payment Service)
  -- All such composition of service calls can be handled in this layer
  -- Again, depending on the environment, you might choose to expose this service as its own DLL and/or expose it as a WCF
  -- Note: this is the only service which will share the references to other services & will be the single point of composition

Now - with this layout - you will have options to call a service directly, if you want to interact with that service alone & you will need to call the composition service if you need a business work flow where different services need to be composed to complete the transaction.

As a starting point, I would recommend that you go through any of the books on SOA architecture - it will help clear a lot of concepts.

I tried to be as short as possible to keep this answer meaningful, there are tons of ways of doing the same thing, this is just one of the possible ways.

HTH.