Home/ Questions/Q 6567167
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T14:18:15+00:00

I have the first large solution that I am working on using MVC3. I

  • 0

I have the first large solution that I am working on using MVC3. I am using ViewModels, AutoMapper, and DI.

To create my ViewModels for some of the more complex edit/creates I am injecting 10 or so
repositories. For all but one of the repositories they are only there to get the data to populate a select list on the ViewModel as I am simply getting associated FK entities etc.

I’ve seen it mentioned that injecting large numbers of repositiories is bad practice and I should refactor. How many is to many? is this to many? How should I refactor? Should I create a dedicated service that returns select lists etc?

Just to to give an example here is the the constructor for my RequirementsAndOffer Controller

       public RequirementsAndOfferController(
IdefaultnoteRepository defaultnoteRepository, 
IcontractformsRepository contractformsRepository, 
IperiodRepository periodRepository, 
IworkscopeRepository workscopeRepository, 
IcontactRepository contactRepository, 
IlocationRepository locationRepository, 
IrequirementRepository requirementRepository, 
IContractorRepository contractRepository, 
IcompanyRepository companyRepository, 
IcontractRepository contractRepository, 
IrequirementcontracttypeRepository requirementcontracttypeRepository, 
IoffercontractRepository offercontractRepository)

All of the above populate the selects apart from the requirementRepository and offercontractRepository which I use to get the requirements and offers.

Update
General thoughts and updates. I was encouraged to consider this issue by Mark Seemann blog article on over injection. I was interested in specifically the repositories and why I was having to inject this number. I think having considered my design I am clearly not using one repository for each aggregate root (as per DDD).

I have for example cars, and cars have hire contracts, and hire contracts have hire periods.

I was creating a repository for cars, hire contracts, and hire periods. So that was creating 3 repositories when I think there should only be one. hire contracts and periods can’t exist without cars. Therefore I have reduced some repositories that way.

I am still left with some complex forms (the customer is demanding these large forms) that are requiring a number of repositories in the controller. This maybe is because I haven’t refactored enough. As far as I can see though I am going to need separate repositories to get the select lists.

I’m considering options for creating some sort of service that will provide all the select lists I need. Is that good practice/bad practice? Should my services only be orientated around aggregate roots? If so having one service providing selects would be wrong. However the selects do seem to be the same type of thing and grouping them together is attractive in some ways.

Would seem my question is similar to how-to-deal-with-constructor-over-injection-in-net

I guess I am now more looking for specific advice on whether a Select List service is good or bad.

Any advice appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You have the right idea starting with a repository pattern. Depending on how you use your repositories, I completely understand how you might end up with a lot (maybe even 1 per database table.)

    You’ll have to be the judge of your own specifications and business requirements, but perhaps you can consider a business layer or service layer.

    Business Layer

    This layer might be composed of business objects that encapsulate one or more intents of your view models (and inherently views.) You didn’t describe any of your domain, but maybe a business object for Users could include some CRUD methods. Then, your view models would rely on these business objects instead of directly calling the repository methods. You may have already guessed the refactoring would move calls to repository methods into the business objects

    Service Layer

    A service layer might even use some of the business objects described above, but perhaps you can design some type of messaging protocol/system/standard to communicate between your web app and maybe a WCF service running on the server to control state of some kind.

    This isn’t the most descriptive of examples, but I hope it helps with a very high level view of refactoring options.

    • 0