为什么MVC如此流行?

因为您将接口与控制器分离,使得更改更容易。

至少我们这样做了,节省了几个月的时间。

它还使UI更改更容易处理,因为在我们的aspx页面中没有任何代码可以执行任何操作。

我们的测试也更好,因为我们可以模拟任何东西,包括按钮点击等。

如果你说的是asp.net-mvc框架,aspx文件中没有代码,没有viewstate等。

模型定义了数据。

视图定义了输出的外观。

控制器是从模型理解语法到视图理解语法的翻译器。

所以基本上控制器是独立的。这个观点是独立的。模型是独立的。

对?不?

我大胆一点,解释一下为什么你的方法不流行。

由于其中一个服务于另一个,并且代码中没有依赖项,因此它让控制器以常规方式运行,因此它所需要做的只是在视图层中采用特定的结构,并在模型层上调用匹配的API。

您将注意到,在视图和模型之间就API达成一致并不是什么大不了的事情,无论如何它都必须发生。您得到的是后端和前端开发之间的良好分离。

在您提出的解决方案中,控制器方面需要进行大量的开发。控制器需要理解视图中的所有元素,并将它们映射到模型层上所需的特定调用。

看一些Struts2的例子来理解我的意思。。。

是的,您可以通过控制器将模型对象转换为非模型对象(如简单数组),使视图仅依赖于控制器。

正如我们已经知道的,如果实际上不需要解耦,那么执行这种转换可能需要付出更多的努力。如果视图使用模型对象,则它具有此依赖关系。但是,通过让视图仅依赖于控制器的所需输入(可以是模型对象),可以稍微减轻这一点。

我好久没回过神来了,主要是因为我还在思考。我对我得到的答案不满意,他们没有真正回答我的问题。

最近,一位教授确实把我引向了正确的方向。从本质上讲,他告诉我这些:分离模型、视图和控制器的层 MVC公司。在vanilla MVC架构模式中,视图与模型之间的依赖关系通常不被使用,并且您实际上最终得到了层。想法是一样的,只是命名很差。

在Microsoft平台上为新的或企业web开发选择表示模式是一项艰巨的任务,在我看来只有三种:视图模型、模型视图表示器(MVP)或ASP.NETMVC(Model2衍生产品)。

你可以在这里阅读全文 ASP.NET MVC Patterns

我想补充一些东西。首先,我的观点是,我们使用模型作为容器,用于传递和显示在视图上的信息。通常,进入控制器的操作方法以返回视图(“viewName”,model)结束。视图本身可能会根据模型更改布局:

在视图上:

如果(model.something==真) {

<

}

在这一点上,很难找到模型的定义。

一个是域模型/实体模型,或者您希望如何调用它,它包装了来自较低层(数据库等)的数据,视图模型包含我们希望显示的信息以及我们需要隐藏/显示接口部分的任何其他信息

脉冲操作结果索引(){

....

如果(model.BoolProperty==真){

return(“第一视图”);

}

其他的

{

return(“第二视图”);

}

}