.Net MVC - Accessing the Database from within a View more than just Bad Practice? [closed]

Question

I've seen a few developers instantiate models that access the database from within a view. Typically they do this when they want to access an html partial and they just create a new viewmodel right there in the view :

<div class='blogListing'>
    @Html.Partial("BlogListing", new BlogListingViewModel(10));
</div>

To me, best practice would be to instantiate all of your models inside your ViewModels, then pass them to your partials. In the example below, BlogHomeViewModel would create a new BlogListingViewModel(10) and set it as a public property for the View to consume :

@Model BlogHomeViewModel

<div class='blogListing'>
    @Html.Partial("BlogListing", Model.BlogListing);
</div>

My question is, is this more than just a bad practice / maintenance issue? Are there also performance concerns for accessing a database from within a View? I would think a model would be able to fire off all of the database requests at about the same time, but within a View you're already starting to render html, and thus must open and close more connections,slowing down page load. Am I off-base here?

Answer 1

As always, there's more than one way to skin a programmer. That's how that saying goes, right?

Years ago when I first started using a MVC framework I kept trying to figure out what the gold standard was for what each letter should be responsible for. There's a lot of opinions, but ultimately it's up to you and your team to figure out what works for you.

I would argue that connecting to the database within your view or model is bad practice. Some people open connections within their models to pull in data. Not me. When I think about what a model is responsible for it's simply:

1. The data that will end up in display in the UI
2. The data that is needed to properly build the UI (e.g. a bool for conditionally showing some options)

I will often refer to my models as "self-sufficient". What that means is my models need to have all the data required by the time it hits the view. I let my controller handle database connections, API calls, LDAP queries and so on. Obviously my controller doesn't contain all of the code for those methods (I have proper specialized libraries for handling different requirements), but, it is the broker between the different sources of data.

What's nice about architecting your applications in this fashion is that you are certain when your heavy lifting is done. You know that when you call return View(model) that you have all the data that you need. You don't have to troubleshoot bad queries (or slow API calls, etc) from your model or view. Having that line drawn as to what each piece is responsible for is what makes the framework useful to me.

Remember, these are my opinions on how the framework should be used. I'm not saying it's the only solution. Your development team might find something more useful, but, keeping this discipline has been working well for me for a handful of years.

Answer 2

The unwritten rule to not access the database from the view is not really about anything other than writing good maintainable code. Developers are always looking for some concrete validation for doing something: it's more performant, etc. Sometimes, you just do things because it won't make the developer that comes after you, well, want to come after you... with a butcher knife.

The whole purpose of MVC (the paradigm, in general) is separation of concerns and proper modularization of code. If you view needs to know how to access the database, you've broken the single-responsibility principle and tied your code in knots, where if database access changes, you need to change the view as well. That's not exactly common sense, so any developer unfamiliar with the codebase can (and Murphy says definitely will) come along and change something that affects that code in the view, without knowing that they affected the view, and your application goes down in flames.