tec*_*ert 32 model-view-controller design-patterns 3-tier n-tier-architecture n-layer
我正在考虑在我的新项目中使用MVC模式,我可以清楚地看到能够将数据层(模型)更接近表示层(视图)的主要优势,这将允许稍微增加在申请速度.但除了性能观点之外,MVC还是在视图 - 逻辑 - 数据分层类型模式上还有其他优势吗？
编辑: 对于那些感兴趣的人我刚刚上传了我创建的示例PHP代码来测试MVC的使用.我故意省略所有安全检查以使代码更容易阅读.请不要过多批评它,因为我知道它可以更加精致和先进,但不过 - 它有效!我将欢迎提出问题和建议:链接如下:http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
Arj*_*jms 42
引用作为MVC优势的关注点的分离实际上也是3层/ 3层系统的进步.业务逻辑也是独立的,可以从不同的表示层使用.
主要区别在于,在经典MVC中,模型可以具有返回视图的引用.这意味着当数据更新时,模型可以将此数据推回到可能的多个视图.主要的例子是桌面应用程序,其中数据以多种方式可视化.这可以像表格和图表一样简单.表中的更改(这是一个视图中的更改)首先通过控制器推送到模型,然后将模型推回到图形(另一个视图).然后图表会自行更新.
由于桌面开发正在逐渐减少,许多程序员只在某些Web变体中接触过MVC,例如通过Java EE中的JSF.
在这些情况下,模型几乎从不参考视图.这是因为Web主要是基于请求/响应的,并且在请求被提供之后,服务器不能发送附加信息.即从模型推送到客户端的更新将毫无意义.对于反向ajax/comet,这种情况正在发生变化,但许多基于Web的MVC框架仍然没有充分利用它.
因此,在基于web的MVC的情况下,M,V和C之间的典型"三角形"在那里较少,并且MVC变体实际上比"真实"MVC更接近n层模型.
还要注意,一些Web MVC框架在M,V和C之间有一个中间管道部分,称为支持bean(Java/JSF)或代码隐藏(ASP.NET).在JSF中,控制器由框架提供,并且视图通常不直接绑定到模型,而是使用此支持bean作为中介.支持bean非常小,基本上只是从模型中预取数据,并将模型特定消息(例如异常)转换为视图特定消息(例如一些人类可读文本).
旁
@bakoyaro和@arjan已经提到了
我认为与"约定优于配置"模式结合使用时,MVC优于3层.(即"ruby on rails"或微软"MVC for asp.net").
在我看来,这种组合可以提供更好,更简单的代码维护.
首先,它使学习mvc-framework更加困难,因为你必须学习约定(la控制器进入controllers文件夹,必须命名为xxxxxcontroller)
但是在学习了这些约定之后,维护自己的代码和外部代码会更容易.
| 归档时间： |
|
| 查看次数： |
56490 次 |
| 最近记录： |