.Net MVC-从视图中访问数据库不仅仅是坏习惯? [英] .Net MVC - Accessing the Database from within a View more than just Bad Practice?

问题描述

我已经看到一些开发人员实例化从视图中访问数据库的模型.通常，当他们想要访问html局部代码时，他们只是在视图中创建一个新的viewmodel来执行此操作:

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>

对我来说，最佳实践是在ViewModels中实例化所有模型，然后将它们传递给您的局部模型.在下面的示例中，BlogHomeViewModel将创建一个新的BlogListingViewModel(10)并将其设置为供View使用的公共属性:

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>

我的问题是，这不仅仅是不良习惯/维护问题吗?从View内部访问数据库是否也存在性能问题?我认为模型可以在大约同一时间触发所有数据库请求，但是在View中，您已经开始呈现html，因此必须打开和关闭更多连接，从而降低了页面加载速度.我在这里基地吗?

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?

推荐答案

与往常一样，为程序员提供皮肤的方法不止一种.那句话是这样的，对吧?

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

几年前，当我第一次开始使用MVC框架时，我一直试图弄清楚每个字母应该负责什么的黄金标准.有很多意见，但最终取决于您和您的团队来确定哪种方法对您有效.

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. 最终将显示在用户界面中的数据
2. 正确构建UI所需的数据(例如bool用于有条件地显示一些选项)

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)

我经常将我的模型称为自给自足".这意味着我的模型在到达视图时需要具有所需的所有数据.我让控制器处理数据库连接，API调用，LDAP查询等.显然，我的控制器并没有包含这些方法的所有代码(我有适当的专业库来处理不同的需求)，但是，它是不同数据源之间的中介.

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.

以这种方式设计应用程序的好处是，完成繁重的工作后，您肯定.您知道，当您调用return View(model)时，您便拥有了所需的所有数据.您不必从模型或视图中解决错误查询(或API调用速度慢等)的问题.弄清每件作品的职责是什么，对我来说框架很有用.

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.

这篇关于.Net MVC-从视图中访问数据库不仅仅是坏习惯?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！