我见过一些开发人员实例化从视图内访问数据库的模型。通常，当他们想要访问 html 部分时，他们会这样做，并且他们只是在视图中创建一个新的视图模型：
<div class='blogListing'>
@Html.Partial("BlogListing", new BlogListingViewModel(10));
</div>
对我来说，最佳实践是在 ViewModel 中实例化所有模型，然后将它们传递给您的部分模型。在下面的示例中，BlogHomeViewModel 将创建一个新的 BlogListingViewModel(10) 并将其设置为要使用的视图的公共属性：
@Model BlogHomeViewModel
<div class='blogListing'>
@Html.Partial("BlogListing", Model.BlogListing);
</div>
我的问题是，这不仅仅是一个不好的做法/维护问题吗？从视图中访问数据库是否还存在性能问题？我认为模型能够几乎同时触发所有数据库请求，但在视图中您已经开始渲染 html，因此必须打开和关闭更多连接，从而减慢页面加载速度。我在这里是不是偏离基地了？
一如既往，给程序员剥皮的方法不止一种。那句话就是这么说的吧？
几年前，当我第一次开始使用 MVC 框架时，我一直试图找出每个字母应该负责的黄金标准是什么。有很多意见，但最终取决于您和您的团队来找出适合您的方法。
我认为在你的视图中连接到数据库or模型是不好的做法。有些人在模型中打开连接来提取数据。不是我。当我思考模型的职责时，它很简单：
- 最终将显示在 UI 中的数据
- 正确构建 UI 所需的数据（例如
bool有条件地显示一些选项）
我经常将我的模型称为“自给自足”。这意味着我的模型在到达视图时需要拥有所需的所有数据。我让控制器处理数据库连接、API 调用、LDAP 查询等。显然，我的控制器不包含这些方法的所有代码（我有适当的专用库来处理不同的要求），但是，它是不同数据源之间的代理。
以这种方式构建应用程序的好处是，您可以certain当你完成繁重的工作时。你知道当你打电话时return View(model)您拥有所需的所有数据。您不必从模型或视图中排除错误查询（或缓慢的 API 调用等）。明确每个部分的职责，使该框架对我有用。
请记住，这些是my关于如何使用该框架的意见。我并不是说这是唯一的解决方案。您的开发团队可能会发现一些更有用的东西，但是，多年来，保持这一纪律对我来说一直很有效。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
