.Net MVC - Accessing the Database from within a View more than just Bad Practice?
asp.net-mvc, asp.net-mvc-4, c#
Solution
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:
- The data that will end up in display in the UI
- 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.
Problem
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?