Question

现在很长一段时间在asp.net MVC上工作今天坚持理论问题在MSDN上查看一些示例代码
我读过这样的内容

public class SomeController()
{
 public ActionResult SomeAction(SomeModel model)
 {
   var dataContext = new SomeDataContext();
   //basic CRUD operations on data context
   //
 }
}

这里数据库显然是通过控制器访问的，理论上是不正确的这个例子有什么问题，或者我对模型和控制器需要刷新的内容的定义更新： -
或者MSDN Models和ViewModels上的每个位置都被认为是相等的

Answer 1

介绍

MVC设计模式相当陈旧。 Smalltalk-80应用程序是originally defined，当“web”是两个在大学之间发送ping的人时。从那以后它有evolved非常多。

MVC设计模式背后的核心原则是Separation of Concerns。该模式将表示与业务逻辑分开。表示层主要包含视图，控制器，模板，视图模型和演示者（取决于您使用的MVC模式的风格），而业务逻辑在模型层中结束。

模型层虽然没有在模式中严格定义，但在ASP.NET MVC中包含服务和服务使用的所有结构（包括模型对象，更好地称为domain objects）。

关于问题

当您在寻找基本的MVC教程时，在控制器中使用DataContext是很常见的。 MVC架构意味着大规模应用程序，而在 Hello-World 示例中，完全实现的MVC架构看起来就像是膨胀。

为简单起见，这些示例牺牲了代码分离。与DataContext的交互基本上是存储逻辑，这是模型层处理的任务之一。当在控制器中使用时，这意味着您的模型层已经开始在表示层中泄漏，并且最终会出现“Fat controller，skinny model”问题。

在实际应用程序中，DataContext将成为处理模型层内持久性的结构的一部分。可能是data mappers的一部分，如果您选择手动编写它们。

关于“更新”

模型（我想在这种情况下，你的意思是Domain / Model对象）来自完全不同的应用层，然后是ViewModel。

顾名思义，在MVVM模式中，ViewModels取代了控制器。 ViewModel从模型层获取数据，然后以可用于View的方式对其进行转换。

当您无法完全控制视图或/和模型层上的行为时，最好使用此模式（如果您实际使用的是MVVM）。例如：如果您被雇用为SAP构建替代前端，或者视图实际上是某种形式的硬件设备，则需要特定类型的输入。

Answer 2

MVC 是一种GUI模式，就像 MVP 或 MVVM 一样，它与数据访问和持久性无关。确实，许多简单的CRUD应用程序并不比MVC和底层数据库多得多，但在更复杂的应用程序中，MVC将成为表示层的一部分。

作为O / RM的DataContext属于基础架构层，而不属于GUI。在MVC中，模型可以理解为 ViewModel ，是的。

然而，控制器可以使用DataContext或任何其他方法从底层数据存储中检索此模型。

Answer 3

模型通常是数据类（表示数据库表）。视图模型通常被称为已创建的类，以便在视图中将它们用于表示目的。

在上述情况下，您无法在视图模型上使用DataContext，但您可以完全使用上述模型类（也称为DTO类）

DataContext是MVC中的Model的一部分还是Controller的一部分？

3 个答案:

介绍

关于问题

关于“更新”