1

I currently have four projects in my website's solution:

Project.Data
This holds the EntityFramework DbContext object and also the Repositories that interact with it. It references Project.Models.

Project.Models
This holds the business objects and doesn't reference any other project

Project.Web
This holds all ViewModels, Views, Controllers and static website content. It references Project.Data (for the Repositories), Project.Models and Project.Service

And now I get to the problem project...

Project.Service
I want this to be the project that Project.Web uses to make its controllers thin, as I understand this is desirable.

Each of the classes in this project will probably have a repository injected into it so they can access any data they need to. One of their responsibilities will be to create a ViewModel for the controllers in Project.Web to use. This means that it will reference Project.Data for a reference to those repositories, Project.Models for the models and Project.Web for access to the ViewModels.

So just as I'm getting the feeling I'm doing something really wrong by all this, I go to add my last reference to Project.Web from Project.Service and it errors out telling me that I now have a circular dependency...

What exactly am I doing wrong here? Are there patterns I can use that will clean up some dependencies on other projects or am I trying to do something that isn't useful anyway?

Improve this question
4
  • 2
    This all looks reasonable and relatively common except; why on earth is Project.Service referencing Project.Web? The "Web" is often called "Endpoint", "Host" or what have you as it is the executable process which runs the service. Given this, it acts as an executor but should provide no facilities to the Service, rather the service should provide facilities to it..
    – Jimmy Hoffa
    Commented May 7, 2013 at 15:08
  • @JimmyHoffa Thanks for your comment. How would I have my Project.Service return ViewModels that live in Project.Web? It seems strange to have my ViewModels (which are quite strongly coupled to the Views) sitting in Project.Service.
    – user33722
    Commented May 7, 2013 at 21:15
  • 3
    You should not. I'm going to presume your service is knowledgeable about logics and it sounds like you're making it the crud endpoint too, so I'll say it should return models (more commonly in MVC the models are the crud endpoints, but you're foregoing that which is fine) and your controllers (or your viewmodels) should know how to transform your models into your view models, so your Web depends on Service and Model, your Service depends on Model and Data, in this structure. That is only one way to lay out a dependency graph, there are many and some are good, though more are bad.
    – Jimmy Hoffa
    Commented May 7, 2013 at 21:37
  • @JimmyHoffa Hmm, I thought the repositories (in the Project.Data) are supposed to return models. If Project.Web is supposed to handle mapping from those Models -> ViewModels, then there's not much else for the Service layer to do...
    – user33722
    Commented May 8, 2013 at 10:18

1 Answer 1

Reset to default
1

I think what you're trying to create is:

Data => Services => Controller | VM => View

But what you're setting up isn't lending itself to that.

As Jimmy Hoffa points out, you need to think of your end-points. It's not clear to me exactly what roles you're intending with your existing project names. So I'll provide my answer using slightly different descriptors. Plug your projects in as appropriate.

Your Data Access Layer(DAL) is an endpoint, as is your Views.

Views will reference the Controller | ViewModel project.

Controller | VM project will reference your Model and / or Services project. Which one(s) depends upon your terminology.

If you have a Model, it will reference your Services project.

Finally, the Services project will reference your DAL.

Improve this answer

Your Answer

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