5

I am designing an asp.net mvc application which uses a service layer. What if we have a service which depends on another service? For, instance, suppose we have the following model:

class UserService : IUserService
{
    //implementation requires IEmailService
}    

Sure, the concrete implementation EmailService can be injected into the constructor of UserService, but in my understanding, a service layer should mediate between UI and Domain Model, it's like a facade. I would define another layer in such a way that UserService depend on IUserModule and IEmailModule, in this way we could break the dependency between services, services being dependent on a lower layer (in my case module layer). Is it a correct approach?

Markus
  • 3,547
  • 10
  • 39
  • 55

3 Answers3

7

Inside a common DDD architecture you'll find two kind of services Domain services (whose coordinate business operations among entities) and Application services (whose depend on the Domain services, and contain tasks related to the application and not to the business logic e.g. export to pdf is an application task. apply a discount is a business logic task).

So if you only have a kind of service, which I suppose covers both responsibilities. is totally valid to have interdependencies.

alt text

SDReyes
  • 9,798
  • 16
  • 53
  • 92
1

Sure, the concrete implementation EmailService can be injected into the constructor of UserService, but in my understanding, a service layer should mediate between UI and Domain Model

Well, it's a contract between to sides, not necessarily UI and Domain Model, but commonly.

it's like a facade.

Yes, a good service features a nice facade also accounting for performance.

this way we could break the dependency between services, services being dependent on a lower layer (in my case module layer). Is it a correct approach?

What does module mean to you? Is IEmailService a service or a module to you? It seems correct to create the Facade in your case for your service. But you provide to few information about your system and your intent and your architectural challenges/priorities.

Falcon
  • 3,150
  • 2
  • 24
  • 35
-4

Dependency injection is something you should avoid as it increases coupling and complexity for an illusion of flexibility. MVC is also something to reconsider before you start your development because it is not good for anything more than simple applications that do CRUD operations. Web Forms is a more proven platform and is better for more usable applications.

  • "Dependency injection is something you should avoid as it increases coupling and complexity for an illusion of flexibility." What? – kyoryu Nov 16 '10 at 04:19
  • Mitch, do you know at all what Dependency Injection or MVC is and how to use it? – Falcon Nov 21 '10 at 10:35
  • -1: Do some research before you advice to "avoid" something. You answer is facing 180 degrees from reality. – Sergi Papaseit Mar 29 '11 at 09:05
  • It depends on ones experience I guess, however I feel MVC is the right way to program for the web and not webforms! :) – Haroon Apr 04 '11 at 06:21
  • @Mitch: You have a lot to learn. Any tool in Software Development is good or bad depending on context. Dependency injection is great for large complex system but terrible for a "Hello, world" apps. MVC is good in more than CRUD apps; but not so good for a quick-and-dirty small project with no long-term maintenance consideration. – Phil Jan 24 '12 at 16:10