我对使用MVC3构建交互式GUI的一般方法很感兴趣。
我们的想法是构建一组可以集成（插入）各种场景的不同组件。
每个组件必须拥有自己的模型定义，控制器和视图。 组件不仅封装了视图，还封装了通过它的控制器的行为。
所有内部实现细节，模型，行为等......必须驻留在组件内部， 使组件变得独立，模块化 - 黑盒子。 这允许在不破坏使用组件的上下文中的任何内容的情况下更改组件。
组件运行的上下文不得对组件实现的内部细节做出任何假设。
另一方面，该组件不会对使用它的上下文做出任何假设。
最后，组件必须提供与外界“沟通”或“互动”的机制。除了内部，组件必须提供某种“外部”接口（如参数，数据，函数，事件......），这将允许组件集成到执行上下文中。
上下文（或场景）是包含组件的部分。 现在，上下文的基本挑战是管理组件之间的交互。
真实世界类别组件示例：
组件显示类别列表，并允许用户执行各种操作，例如排序，分页和记录选择。 在内部，它有自己的模型，存储相关信息，如当前页面，排序，选择等... 在内部，它在其自己的控制器中实现所有必需的操作（用于基本渲染，用户操作响应等）。 在内部，它处理视图中的模型状态持久性，并在其自己的控制器中处理模型状态恢复。
真实世界产品组件示例：
组件显示产品列表，并允许用户执行各种操作，例如排序，分页和记录选择。 在内部，它有自己的模型，存储相关信息，如当前页面，排序，选择等... 在内部，它在其自己的控制器中实现所有必需的操作（用于基本渲染，用户操作响应等）。 在内部，它处理视图中的模型状态持久性，并在其自己的控制器中处理模型状态恢复。
真实世界信息中心页面（上下文，场景）示例：
页面显示“类别”和“产品”组件。 产品组件显示当前所选类别的所有产品，因此必须提供外部接口（参数或其他内容）以从上下文接收所选类别标识符。 类别组件必须提供某种外部接口，以便上下文可以在选定的类别更改时执行操作，并为产品组件提供选定的类别标识符。
从技术上讲，页面更新的通信方法主要通过AJAX，但如果没有AJAX就可以实现，那就更好了。
对于AJAX，我希望解决方案使用服务器端控制器决定并呈现应在客户端更新的内容（JSON或其他）。
我会在客户端脚本（客户端“喜欢”控制器）中不喜欢解决方案，它决定要调用哪些操作以及要更新的页面部分 - 这必须在前一段中说明通过服务器上的控制器。
重要提示：通过某种途径直接调用时，组件不一定有效。
您通常如何实施所描述的系统？
答案 0 :(得分：4)
我认为您需要调查实际项目，看看您需要使用哪种方法。尝试以下项目，您可以找到许多最佳实践：
在这里，你可以找到安全措施，服务，auth和许多有用的实现。
Kigg
http://www.nopcommerce.com/downloads.aspx
http://orchard.codeplex.com/
我很难说应该如何实施。更好地编码。但在您的情况下，必须使用Dependecy Injectction of Views，Controllers，Services和Repositories。
答案 1 :(得分：1)
在我看来，你正在努力实现一些可能与 web MVC （MVC的其他实现可能支持它）的理念不相容的东西。 / p>
但是，如果你想在ASP MVC上编写框架的麻烦，我相信你可以实现你想要的。例如，通过使用区域，您可以实现控制器，视图模型和视图的封装形式。
要为同一主视图组合不同的区域，您可以编写具有自己视图的前端控制器的等效视图，该视图模型将由前端控制器准备，以呈现来自不同区域的操作
通过在ASP MVC之上使用Backbone.js等客户端框架，您可以获得更多里程。
答案 2 :(得分：1)
每个控制器处理整个用户机器模式。也就是说，粗略地说，每个控制器负责为用户案例编排用户 - 机器交互（用户机器模式是analysys阶段的结果）。 现在，如果你把＆＃34;标准行为＆＃34;在控制器谁将协调用户 - 机器交互模式？ 通过这种方式，您将拥有＆＃34;组件＆＃34;没有协调执行的东西。 在Web表单中，您有一些页面可以协调放入其中的组件的执行...但是在Mvc中，协调员角色由控制器本身扮演。
您可以执行由控制器和视图组成的黑盒，只要它们中的每一个都负责整个用户 - 机器交互模式。这是一个＆＃34;大组件＆＃34;不是一个小的构建块，因为实现CMS时就是这种情况。
The Orchard CMS use a similar approach。然而，您所谓的组件实际上是预定义的块，它们扮演着用户正在构建的网站的整个部分的角色。