c# - ASP.NET MVC设计问题

Question

Model和ViewModel有什么区别？我应该同时使用它们还是最好跳过其中之一？谁从数据库中获取数据？
我想知道什么是从数据库中获取数据的最佳/正确方法。


一种选择是拥有DAL（数据访问层）并在每个控制器中实例化它，
像这样填充视图模型：

var viewmodel = Dal.GetArticles();

另一个选择是让模型本身从数据库中获取信息：

var model = new ArticlesModel();
model.GetArticles();

public void GetArticles()
{
var context = new DbContext();
_articles = context.Articles
}

另一个类似的选择是使用静态DAL，以便您可以在每个模型中访问它，
因此，每个模型都有一个使用静态DAL类（其中包含一个DbContext类以访问数据库）来获取数据的方法。

public void GetArticles()
{
_articles = DAL.GetArticles();
}

因此，通常的问题是模型本身是否需要从数据库中获取数据，或者控制器本身可以访问DAL。

Answer 1

当有人在写一个更有用的答案时，我会尽快解决您的观点。

Model是要显示的数据。

通常，您将需要使用对象关系映射，因此大多数业务对象类都与数据库表相对应，并且您不必手动构造查询。

有很多可用的ORM解决方案，包括Entity Framework，NHibernate和（即将消亡的）LINQ to SQL。

还有一个很棒的微型ORM，称为Dapper，如果更大的框架对于您的解决方案来说不必要地膨胀，您可能会喜欢。

确保您了解它们之间的区别。

在.NET中，DAL比classes that “know” how to load themselves更惯用。

（尽管在实践中，您的解决方案很可能是两种方法的结合，但关键是像往常一样保持平衡。）

我的建议是，只要您的ORM允许并且不给调用代码增加额外的复杂度，就尝试保持模型plain old CLR objects。

这些对象在任何可能的情况下（并且明智的—任何规则都有例外！）都不应与特定的数据库或ORM实现绑定。

如果需要，将代码迁移到另一个ORM只需重写数据访问层即可。
但是，您应该了解，这不是分离DAL的主要原因。

您极不可能在项目的中间阶段更改ORM，除非您最初的选择确实不适合该目的，或者您突然吸引了100,000个用户，而您的ORM无法处理。从一开始就对其进行优化是非常愚蠢的，因为它使您无法创建一款出色的产品，该产品能够吸引您针对其进行优化的点击量。 （免责声明：我之前走过这条路。）

相反，DAL的好处是您对数据库的访问总是显式的，并且限制在您希望发生的某些地方。例如，接收到要显示的模型对象的视图将不会尝试从数据库中加载某些内容，因为实际上这是控制器的工作。

通常，将业务逻辑，表示逻辑和数据库逻辑之类的东西分开也很好。它经常导致更好的，更少的错误代码。另外：您可能会发现很难对依赖于从数据库加载的对象的任何代码进行单元测试。另一方面，使用LINQ来创建“伪”内存数据访问层是微不足道的。

请再次记住，该规则也有例外，例如由许多ORM生成的惰性属性将随时随地加载关联的对象-即使在视图中调用也是如此。因此，重要的是您应该做出明智的决定，何时允许访问数据以及为什么访问。语法糖可能有用，但是如果您的团队不了解从ORM加载20,000个对象对性能的影响，那么它将成为一个问题。

在使用任何ORM之前，请先learn how it works under the hood。

在Active Record风格的对象和DAL之间进行选择主要取决于口味，.NET中的常见习惯，团队习惯以及最终必须替换DAL的可能性。

最后，ViewModel是另一种野兽。

尝试这样思考它们：


视图中不应包含比if-then-else更复杂的逻辑。
但是，通常在显示事物时会有一些复杂的逻辑。
考虑分页，排序，在一个视图中组合不同的模型，了解UI状态。


这些是视图模型可以处理的事情。
在简单的情况下，它只是将几种不同的模型组合为一个“视图模型”：

class AddOrderViewModel {
    // So the user knows what is already ordered
    public IEnumerable<Order> PreviousOrders { get; set; }
    // Object being added (keeping a reference in case of validation errors)
    public Order CurrentOrder { get; set; }
}

模型只是数据，控制器组合数据并引入一些逻辑来描述要在视图模型中显示的数据，而视图只是渲染视图模型。

视图模型还可以用作一种文档。他们回答了两个问题：


我可以在视图中使用哪些数据？
我应该在控制器中准备什么数据？


与其将对象传递到 ViewData并记住它们的名称和类型，不如使用 generic views并将内容放入 ViewModel的属性中，这些属性是静态类型的并且可与IntelliSense一起使用。

另外，您可能会发现创建 ViewModel层次结构很有用（但请不要极端！）。例如，如果您的站点范围导航从面包屑更改为其他内容，只需替换基本视图模型上的属性，显示该视图的局部视图以及在基本控制器中构造它的逻辑，这是很酷的。保持明智。