ASP.net MVC : IS this pattern reasonable or conceptually incorrect?

Question

My controllers turn over the request to the appropriate service. The Service then makes calls to various Repositories. Repositories use Linq to Sql Entities purely for DataAccess and then map and return as Domain Objects. The service then decides what the Controller will present and replaces the DO with Presentation objects which are returned to the Controller to display in View.

SO I have Services-Repositories-Domain Objects- Presentation Objects

I am asking because it seems like i have a lot of objects, some not doing anything but passing data. Is this a reasonable scenairo or am i not following proper MVC pattern?

Answer 1

If your application is big enough, your pattern makes sense. Otherwise, I smell overengineering...

Ask yourself: what if this layer didn't exist and you'll find out if it's true or not.

Answer 2

Yes, you've got the right idea. It can be a lot of classes and interfaces (not even counting the unit tests and mock/test classes) but if you have a decent sized application, you're libel to have many anyway. But to start out, it's a lot of work for not much initial gain.

I have seen projects skip the some of the services implementations for basic services that just pass through to the repository without any value added by the service. They go straight to the repository from the controller and don't seem to lose much.

There are other ways to ease the burden of some classes by using tools where possible. For example, projects like AutoMapper can help streamline your domain object to view model mappings.

Answer 3

I had a very similar scenario. Initially my project had UI, Controllers, Service Layer and Repositories. My unit tests covered both the service layer and repositories (filters) and in some cases the unit tests were doing the same thing (as the service layer was sometimes a pass through to the repositories).

Due to a large refactor I cut out the service layer and this gave me a lot of flexibility with the Controllers dealing directly with the Repositories and applying Filters to get exactly what I want.

One problem I ran into was you cannot Serialize Linq2Sql objects and therefore sometimes had to translate these object to presentation objects.