1

In Mark Seeman's Dependency Injection in .NET he injects a repository into his UI layer. I believe that he is doing this so that he can store everything in the UI configuration, however this just strikes me as bad design. Wouldn't it be better to pass the service reference into the UI? What is to stop a future developer from using the repository directly? Also, he says that he is building this as an n-tier architecture. But, he has now coupled the data layer to the UI layer (no matter if DI is used or not). What if he wants to host all three layers on different self-contained servers. While his approach COULD work, it just seems wrong to me. So, I wanted to see what the general community has to say. Am I right in my thoughts, or am I missing something?

Simplified version of the code:

public class UI
{
  IRepository _repo;
  public UI(IRepository repo) 
  {
    _repo = repo;
  }

  public stuff UIMethod()
  {
    var svc = new Service(_repo);
    return svc.GetStuff();
  }
}

public class Service
{
  IRepository _repo;
  public Service(IRepository repo)
  {
    _repo = repo;
  }

  public stuff GetStuff()
  {
    var persistenceStuff = _repo.GetStuff();
    //Do some business logic here
    return persistenceStuff.ToServiceStuff();
  }
}
3

imo, passing the repo through the service is pointless. Why have the service at all, if you're just going to use the repository?

I think that every layer of abstraction needs to be thought out. If you don't need a service, don't have one. If you don't need a repository (most are DAO's anyway), don't have one.

I agree with you. As that code stands, it's bad design. He should either remove his Service layer and reference the Repository directly, or use the Service. Typically you shouldn't pass references of objects through other objects.

  • +1, but you and I are in total agreement :p. I will probably leave the question open for a week or so just to see if anybody has a compelling argument against us, though...to be safe :) – Justin Pihony May 29 '13 at 18:00
2

But, he has now coupled the data layer to the UI layer

The purpose of a repository is to decouple the user of the repository (here the UI layer) from the persistence or database layer - not from the data objects itself. It helps you, for example, to provide in-memory generated data objects for testing purposes, without the need of retrieving them from a real database.

  • But, my point is that you are still exposing the persistence layer (however implemented) in the UI layer when you only need it in the service layer. – Justin Pihony May 29 '13 at 15:49
  • @JustinPihony: No, your data objects can be just simple POCOs - as long as your persistence framework (typically an ORM mapper) supports that. So your "data object layer" is not tied to the persistence layer, and also isn't your UI layer. – Doc Brown May 29 '13 at 15:52
  • But, that would be if you had only two layers: UI and persistence. In the three tier architecture that is being used, the service is the only thing that cares about the persistence layer. In fact, the repository is only being pulled into the UI to pass into the service layer. – Justin Pihony May 29 '13 at 15:55
  • @JustinPihony: well I am not sure if we have the same thing in mind when talking about a "service layer" - do you mean a "business" or "domain layer"? I thought so, and a repository decouples the UI from persistence as well as the domain layer, too. – Doc Brown May 29 '13 at 15:59
  • I updated my answer to have simplified, contrived for readability example. – Justin Pihony May 29 '13 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.