CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-3design-patterns
Radu D
Radu D

Reputation: 3555

ASP MVC 3: Is dependency injection in ViewModels a good idea?

I am facing a design issue with an mvc 3 app. I have a viewmodel ProductCreateModel that has a list of Categories.

Now I am setting the Categories list in the controller, but I am thinking if it is a good idea to indect the datasource in ProductCreateModel constructor.

Do you think that view models should be fat models that also know to read dependent data from the data source? ... or this is a controller thing?

Upvotes: 3

Views: 1017

Answers (4)

SwampyFox
SwampyFox

Reputation: 1105

As a general rule, I don't think you want to do that.

As an exception to that rule, I've started using a little bit of Service Locator in my Editor Templates when creating drop downs. I've gone through multiple ways of populating drop downs (generally, some form of adding a collection to either the view model or into view data). I saw a video where SL was used in the Editor Template to get the data and then convert to a Select List. My initial reaction was "ugh, really?", but, the more I thought about it, it made sense.

Upvotes: 0

Troy Sampson
Troy Sampson

Reputation: 141

When I learned MVC I was taught that the "rule of thumb" is Skinny Controllers, Fat Models, Dumb Views. A mistake that many MVC developers make is Fat Controllers (too much logic), Skinny Models (basically POCO classes to hold data), and Smart Views (a bunch of Razor Syntax with If this, Else that, etc.)

Over the years I've stuck to the Skinny Controllers, Fat Models, Dumb views approach, and it has worked well for me. Now, take into consideration that this is related to Models and not ViewModels. Usually your Models should be in an entirely different layer (i.e. proj or folder). ViewModels, on the other hand, should be fairly simple. This makes them easier to test, and more reusable. If you are finding that you need some sort of service, repo, or other dependency to build up your ViewModels, then you should probably abstract that logic out into some sort of Composer Class. In the past I've used a ViewModelManager which implements IViewModelManager, to compose my ViewModels if need be. This way you can inject IViewModelManager into your controller, and use it to build your ViewModels. Then, in your ViewModelManager implementation, you can inject your other dependencies, like repos, services, etc. to actually construct your ViewModel.

This approach definitely requires more code, and many more classes, but it will give you a good level of granularity, and separation, plus support the DRY principle along with Single Responsibility.

Happy Coding!

Upvotes: 3

Steen Tøttrup
Steen Tøttrup

Reputation: 3835

I think view models should be light models, and the only way for them to read related data, should be properties on "parent" object, the model they actually wrap.

Most of the time my view models are just classes with properties, all logic are in the controller or in a service class (if we're talking a lot of logic that would otherwise be put in the controller). All this is in the name of easier testing.

Upvotes: 6

Sergei Rogovtcev
Sergei Rogovtcev

Reputation: 5832

I prefer slim viewmodels that do not know a thing about data layer. They are easier to manage (in my experience).

Upvotes: 6

Related Questions