小编cor*_*e24的帖子

在ASP.net MVC的页面构成框架的批评中,我发现很难与任何东西争论.

http://www.matlus.com/problems-with-asp-net-mvc-framework-design/

特别是这些要点:

• 无权访问视图或部分视图实例
• ViewData是您的松散类型信息载体
• 控制器并没有真正掌控
• 子操作没有请求上下文的意义
• 视图与控制器耦合

对于小型应用程序,我认为很多这些都不是很大的问题,但是在大型应用程序中,您希望重用大量共享组件,或者即使您只是拥有一个依赖于多个应用程序的大型应用程序后端信息源获取渲染视图所需的所有信息,它开始崩溃.

已经提出了针对这些问题的各种半解决方案,但是它们看起来不能很好地扩展或具有不期望的设计约束.

以下是一个示例应用程序场景:

1. 50%的页面内容在应用程序的所有页面中都是通用的(页眉,页脚,菜单等)
2. 您的应用程序实际上可能包含多个区域,每个区域都有自己的控制器等,以便进行独立开发.
3. 公共页面内容中的许多页面元素(菜单,页面标题信息,页脚,公开内容)需要一个或多个服务调用来填充用于呈现的数据.

好的,所以在asp.net mvc3中,假设您决定要共享包含50%常见UI标记的常见Razor布局.这有助于分离关注,因为应用程序开发人员不需要关注常见的ui,并且可以专注于特定于其专业领域的逻辑和视图.

但是,在这种共享布局需要数据(一些或多个模型类型的某些外观)来完全呈现自身的情况下,这完全崩溃了.您可能在页面上有独立元素,每个元素都需要特定的数据模型,例如:*主菜单模型*二级菜单模型*页脚链接模型*授权模型*页脚免责声明模型

并且这些模型中的每一个可以具有单独的源.因此,尽管您可以共享模板,但是没有一种简单的方法可以共享逻辑来构建每个模型 - 而且我所看到的绝对没有一个是通用的,可扩展的和高性能的.

我见过的一些解决这个问题的方法是:

• 强烈键入公共布局,这需要所有视图模型子类化公共基础模型类.(但是没有通用的解决方案来填充这样的元模型,这限制了设计并使模型变得庞大且难以测试)此外,模型群体仍然落在每个控制器上,违反了关注点和单一责任原则,通过堆积大量额外逻辑来复杂单元测试控制器,以填充元模型以及特定于视图的模型信息.
• 保持公共布局无类型,因此您不必从公共基础模型继承,但这需要您使用ViewData或ViewBag来传达模板所需的所有不同模型,这样您就会失去强大的输入优势并最终得到松散的数据合同.你仍然存在缺乏填充元模型的一般解决方案的问题以及所有这些问题.
• 每个控制器都必须子类化公共基本控制器类以支持公共布局和模型.构建元模型的共同方面的逻辑就在这里.但这并不总是理想的架构或设计约束.这至少解决了关注问题.
• 在公共布局中,通过RenderAction()使用子操作而不是元模型来制作可重用的"portlet"样式小部件,每个小部件都独立知道如何构建其数据模型并将其提供给他们的视图.这对于Separation of Concerns来说确实很好,但是有一些缺点:在通过子操作渲染期间有效地进行服务调用的视图,子操作完全不知道原始请求上下文,违反了DRY原则,因为每个子操作都不知道之前已经发生了什么,所以每个人都可以在同一个http请求中反复拨打相同的服务电话,以及其他人.想象一下,所有需要独立调用RenderAction()的页面的20-30个元素......

还有其他情况(一些在stackoverflow上也可以看到),其中RenderAction()作为解决方案存在其他问题.例如,在循环中发出多个RenderAction()调用会导致所有这些控制器方法的串行执行.没有机会与RenderAction()并行.每个子控制器操作中的I/O绑定服务调用会导致整个呈现过程在I/O上等待.控制器只知道其直接视图和模型,并且没有任何内容可以全面了解视图内部的内容,以便并行化某些操作.

上述评论的作者在ASP.Net mvc之上开发了一个不同的UI模型,称为Quartz,允许上帝控制器对视图有深入了解,并且可以将每个视图模型交给视图模型,因此有机会并行化服务调用.构建这些视图模型的中心位置.我不知道这是否是提供克服问题的钩子的最佳设计,但看起来很有希望.

我的问题是,在ASP.Net MVC上构建复杂应用程序的最佳实践是什么,它可以干净地解决这些问题？我已经想到了几种可能性(尽管在ASP.Net MVC中没有一种可能是实用的 - 也就是TBD),但其他人必须已经遇到过这种情况.ASP.Net MVC中的设计模式是什么,或者什么是派克可以使这成为一个容易处理的问题？