.Net MVC - Accessing a Database from Inside View is More Than Just Bad Practice?

Question

I have seen several developers create models that access a database from a view. Usually they do this when they want to access the html particles, and they just create a new viewmodel right in the view:

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

For me, it would be best practice to instantiate all of your models inside your ViewModels, and then transfer them partially. In the example below, BlogHomeViewModel will create a new BlogListingViewModel (10) module and set it as a public property to use View:

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

My question is, is this not just a problem with bad practice / service? Are there also performance issues for accessing the database from the view? I would have thought that the model would be able to remove all database queries at about the same time, but inside the view you are already starting to render html and, therefore, should open and close more connections, slowing down the page loading. Am I out of base here?

Answer 1

As always, there is more than one way to hide a programmer. As the saying goes, right?

A few years ago, when I first started using the MVC framework, I kept trying to understand what the gold standard is, for which every letter should be responsible. There are many opinions, but ultimately it is up to you and your team to find out what works for you.

I would say that connecting to a database in your view or is a bad practice. Some people open connections in their models to retrieve data. Not me. When I think that the model is responsible for this simply:

• Data to be displayed in the user interface
• Data necessary for the correct assembly of the user interface (for example, a bool to conditionally display some parameters)

I often refer to my models as "self-sufficient." This means that my models should have all the data needed by the time they get into the view. I allow my controller to access database connections, API calls, LDAP requests, etc. Obviously, my controller does not contain all the code for these methods (I have the appropriate specialized libraries to handle different requirements), but it is a broker between different data sources.

What a pleasure to do with the architecture of your applications in such a way that you are sure that your hard climb is done. You know that when you call return View(model) , you have all the necessary data. You do not need to troubleshoot faulty requests (or slow API calls, etc.) from your model or view. When this line refers to what each part is responsible for, this is what makes the frame useful to me.

Remember, these are my opinions on how to use the structure. I am not saying this is the only solution. Your development team may find something more useful, but, while maintaining this discipline, it has worked well for me for several years.

Answer 2

The unwritten rule of not accessing the database from the view has nothing to do with writing good supported code. Developers are always looking for some specific check in order to do something: it is more perfect, etc. Sometimes you just do something because it doesn’t make the developer who comes after you, well, you want to follow you ... with a butcher knife.

The whole goal of MVC (paradigm in general) is to separate problems and correctly modulate code. If you think you need to know how to access the database, you have violated the principle of uniform responsibility and tied your code in nodes, where, if access to the database changes, you also need to change the view. This is not common sense, so any developer who is unfamiliar with the code base can (and Murphy says confidently) come and change something that affects this code in the view, not knowing that they influenced the view, and your application crashes in the flame.

Answer 3

I do not believe that when you call the database from your view there will be performance problems. All this is processed in IIS anyway, before it ever gets to the browser. The only exception is if you open / close connections several times.

As a rule, the main reason for keeping the separation of problems is that each part of MVC has a specific responsibility, and you do not look at everything to find out where this data came from.

In addition, from the point of view of unit testing, you want to keep access to the data in a place where it can be tested, and the presentation is not very good for this.