Home/ Questions/Q 6861783
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T02:34:47+00:00

I am setting up an MVC solution and trying to seperate it out into

  • 0

I am setting up an MVC solution and trying to seperate it out into logical projects. So far, I have the following projects:

  • MVC (presentation layer, Models folder contains only ViewModels)
  • Services (provides business logic, has interfaces and providers folders)
  • Repository (for persistence, has interfaces and providers folders)
  • Domain (POCO)

The mvc layer references the service layer and service references the repo. All three reference the Domain so that I can pass the POCOs between them.

Does this setup make sense in that I could potentially use a different presentation layer in the future which would again work via the service layer?

At the other end, would my Domain layer allow me to swap out one ORM for another without breaking? Am I right in thinking that as long as the repo classes in the Repo layer implement interfaces, I could create a new set of concrete repo classes which work with a different ORM?

Sould my DbContext live in the Repo layer with the EF implementations? Is this where a UoW would go?

Can my Services do basic validation using the Annotations on the Domain POCOs or should I use a tool such as Fluent Validation?

Finally (!) would it be correct to create a sepereate Test project for each layer (where appropriate)?

Thanks in advance for all help,

James

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As long as you make sure that you are developing against an interface, not an implementation this would definitely work.

    We are developing applications with a similar architecture to what you are suggesting.

    Our presentation layer uses MVP so we can share our presenters between ASP.NET Webforms and other frontends. In that we use a ServiceFactory which uses dependency injection to create our services. This could be a WCF client proxy or a direct service. The presenter doesn’t need to now if the call is going over WCF or directly.

    In our Service layer we use a UnitOfWork that wraps a set of Repositories. The UoW is also constructed trough DI.

    We use the Entity Framework and generate POCO objects from it. We only choose to not share the POCO’s all the way to the presentation/view layer but only in the business and service layer. From the service layer to view we use custom DTO’s. Currently EF and the UoW live in the same project. We could move them to another assembly and load them from there but in practice it wouldn’t make any difference (and we want to avoid the whole ‘number of projects’ explosion each time we load the solution file).

    We perform our validation partly in the POCO entities and in the Service Layer (which maps the DTO’s to the POCO’s and can check the data). Also we validate incoming data in the presenter and in javascript in the view (for a nice user experience). We currently don’t use a tool for the validation.

    And yes, we have a test project for each layer.
    We test the Presenters, Services and the UoW/Repositories. On our build server we run continues integration which runs all unit tests in a couple of different setups (in memory, against the database, using WCF).

    Off course if you would only test your Presenters this would also hit the services and the datalayer but if you mock all dependencies you can test each layer in isolation (especially for the cases where another layer should trow an error or something, which is a lot easier to do when you mock the whole layer).

    The only thing I’m currently looking at is testing the actual views. We’re currently not testing them in automatic way. Maybe we’re going to use Coded UI tests or some javascript framework.

    • 0