ASP.NET MVC设计问题

Question

1. Model和ViewModel有什么区别？ 我应该同时使用它们还是最好跳过其中之一？ 谁从数据库中获取数据？

2. 我想知道什么是从数据库中获取数据的最佳/正确方法。

一种选择是拥有一个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比“知道”如何进行自身加载的类更为习惯。

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

我的建议是，只要您的ORM允许并且不给调用代码增加额外的复杂度，就尝试将模型保留为普通的旧CLR对象 。

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

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

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

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

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

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

在使用任何ORM之前， 请先了解其工作原理 。

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

最后， ViewModel是另一种野兽。

尝试这样思考它们：

1. 视图中不应包含比if-then-else更复杂的逻辑。
2. 然而，往往是在显示一些一些复杂的逻辑。
   考虑分页，排序，在一个视图中组合不同的模型，了解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; }
}

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

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

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

与其将对象传递到ViewData并记住它们的名称和类型， ViewData使用通用视图，然后将内容放入ViewModel的属性中，这些属性是静态类型的，可通过IntelliSense获得。

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

Answer 2

模型代表您喜欢数据的结构，而不关心可能会占用它的视图。 模型的意图纯粹是表示结构的意图。

一个模型可能包含与使用它的视图无关的属性。

设计视图模型时要考虑到视图。 视图模型旨在与视图建立一对一关系。 视图模型仅包含其预期使用的视图所需的基本字段和属性。

通常，您将让您的控制器与存储库（在您的示例中为DAL）联系，以获取数据，然后使用结果填充模型或视图模型，并将其发送到视图。

Answer 3

模型（域模型） ：是应用程序的心脏，代表最大和最重要的业务资产，因为它捕获了所有复杂的业务实体，它们之间的关系和功能。

ViewModel ： ViewModel位于模型之上：ViewModel的两个主要目标是：1.使模型易于被视图使用；以及2.将模型与视图分离和封装。

例如。

模型：

public class Product
{
...............
}

public class Category
{
...........
}

视图模型：

public class ProductViewModel
    {
        public ProductViewModel(List<Product> products, List<Category> categories)
        {
            this.Products = products;
            this.Categories = categories;
        }

        public List<Product> Products { get; set; }
        public List<Category> Categories { get; set; }

    }