we are modelling an application using the "Service-Provider" pattern, where the service will offer a generic functionality implemented by different providers registered on the service.

The responsibility of the service will be to choose the right provider based on certain conditions.

The layers we currently have are the following ones:

enter image description here

What I don't like about this approach it that the client needs a reference to the providers to access the A definition. I think that normally dependences should go only from one layer to its layer below, right?

One solution could be duplicating the model on the service layer but that would mean duplicating ... and of course we should avoid that:

enter image description here

Another solution could be creating a package only for models, but this could be overkill and also breaks the top - down dependency chain:

enter image description here

I'm not happy with any of these solutions but I currently do not have others. What do you think, do you like any, are there others that I have not thought about?

Thanks in advance.

  • Please read up on Inversion of Control. martinfowler.com/articles/injection.html Also, your view of "top-down dependency" is vague. What defines "a layer below"?
    – rwong
    Jul 18, 2013 at 13:38
  • @rwong: each layer offers services to higher layers and uses services offered by lower layers. I thought this was something commonly agreed. Jul 18, 2013 at 13:58
  • 1
    It is summarized more clearly on the Wikipedia article on Dependency inversion, in particular both layers should depend on abstraction (interface). In other words, your third diagram (everything depend on Model) is a commonly accepted choice.
    – rwong
    Jul 18, 2013 at 14:04
  • 1
    @rwong: I agree. The diagram is simplified. In the real world each package turns to be two packages, one with implementation and another one with shared interfaces. Anyway the question still remains the same. Jul 18, 2013 at 14:10
  • Agreed with @rwong, I tend to create a "contract" assembly which has no dependencies so anyone can use it without depending on any odd extra bits. You can create a monolithic one that has every packages contracts and this is harmless because they have no dependencies, but not generally preferred, alternatively you create a contract per package. Either approach is totally valid but your contract should be segregated from your implementation. Jul 18, 2013 at 15:50


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.