asp.net-mvc – 为什么在MVC中传递实体不是一个好主意?
我们正在使用MVC 2 RC2开发一个相当大的应用程序,并且我们收到了一些有关使用实体框架的延迟加载方式的反馈.
我们只是在控制器中获取实体,并将它们作为模型发送到视图,这导致视图代码要求数据库获取我们正在使用的导航属性.我们已经看过这个,看起来不是一个好的设计,但是我们想知道为什么? 你能帮我们理解这个设计问题吗? 谢谢! 解决方法
这里的主要问题是耦合.模型背后的想法,即“MVC”中的“M”,它没有外部依赖.它是您的应用程序的“核心”.精心设计的应用程序架构的依赖关系树应该是这样的:
+---------------------------------------> Views | | | | | v Controllers ----+-> Model Transformer -----> View Model | | | | v v Data Access <---- Persistence --------> Domain Model | / | / v / Mapper ------+ 现在我意识到说“这里是一个架构,这是你应该使用的”并不完全令人信服,所以让我来解释一下这里发生了什么: >控制器接收请求. 那么为什么这么好? >域模型没有依赖关系.这是一件非常好的事情,这意味着执行验证,写测试等很容易.这意味着您可以在架构中的任何地方更改任何内容,并且永远不会破坏模型.这意味着您可以跨项目重用该模型. 现在,当使用诸如Linq的O / R映射器到SQL或实体框架时,将它们生成的类视为域模型是非常诱人的.它看起来像一个域模型,但它不是.为什么? >实体类与您的关系模型相关联,随着时间的推移,您的关系模型将与您的领域模型大相径庭; 实体框架类不是域模型.它们是数据关系模型的一部分,并且具有与域模型中的类相同或相似的名称.但依赖管理方面却是世界分明的.使用从ORM工具生成的类作为域模型只能导致非常脆弱的架构/设计;您对应用程序的几乎任何部分所做的每个更改都将具有一系列可预测和不可预测的级联效应. 有很多人似乎认为你不需要一个凝聚力,独立的领域模型.通常的借口是(a)它是一个小项目,和/或(b)他们的领域模型真的没有任何行为.但小项目变大,业务规则变得越来越复杂,一个贫穷或不存在的域名模型不是简单的重构. 这实际上是实体模型设计中最阴险的特征;似乎工作正常,一段时间.当你淹没在缺陷报告和变更请求中时,你不会发现这是一个错误,直到一年或两年,而拼命地将真正的领域模型拼凑在一起. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- asp.net-mvc – MVC4是否被烘烤到.NET 4.5?
- asp.net – 表单身份验证是否与Web负载平衡器一起使用?
- 如何为新项目决定WebForms vs ASP.NET MVC 3?
- asp.net-mvc – ASP.NET MVC:具有POST Action参数的Redire
- ASP.NET – 图像未显示
- .net – ashx vs aspx文件下载
- asp.net-mvc – 如何处理返回ViewResult以外的结果的操作的
- ASP.Net注销代码块
- asp.net – 如何使用HtmlEncode与TemplateFields,数据绑定和
- asp.net-mvc-3 – @ Html.DropDownList width
- 编辑并在ASP.NET Web项目中继续
- [译]在Asp.Net Core 中使用外部登陆(google、微
- asp.net – 谁应该负责分页控制器/ domail服务/存
- asp.net-mvc – Ninject.MVC3,将DependencyResol
- 为ASP.NET/ASP.NET MVC配置IIS(Windows 7)3
- asp.net – 如何配置IIS Express来调试子目录中的
- asp.net – 如何调用我的WCF服务构造函数?
- 限制面向公众的asp.net应用程序演示站点?
- asp.net – 如果启用ASP .Net请求验证,是否需要H
- asp.net – 如何在控件中显示十进制值?