MVC 组件 GUI 方法答案

【问题标题】：MVC component GUI approachMVC 组件 GUI 方法
【发布时间】：2012-03-24 12:49:03
【问题描述】：

我对使用 MVC3 构建交互式 GUI 的一般方法感兴趣。

这个想法是构建一组不同的组件，可以集成（插入）到各种场景中。

每个组件必须有它自己的模型定义、控制器和视图。组件不仅封装了视图，还通过它的控制器封装了行为。

所有内部实现细节、模型、行为等...必须位于组件内部，使组件变得独立，模块化 - 黑匣子。这允许在不破坏使用组件的上下文中的任何内容的情况下更改组件。

组件运行的上下文不得对组件实现的内部细节做任何假设。

另一方面，组件不会对将使用它的上下文做出任何假设。

最后，组件必须提供与外界“通信”或“交互”的机制。除了内部，组件还必须提供某种“外部”接口（如参数、数据、函数、事件等等……），以便将组件集成到执行上下文中。

上下文（或场景）是包含组件的部分。现在，上下文的基本挑战是管理组件之间的交互。

真实世界的类别组件示例：

组件显示类别列表并允许用户执行各种操作，例如排序、分页和记录选择。在内部，它有自己的模型来存储当前页面、排序、选择等相关信息...... 在内部，它在自己的控制器中实现所有必需的操作（用于基本渲染、用户操作响应等）。在内部，它在自己的控制器中处理视图中的模型状态持久性和模型状态恢复。

现实世界中的产品组件示例：

组件显示产品列表并允许用户执行各种操作，例如排序、分页和记录选择。在内部，它有自己的模型来存储当前页面、排序、选择等相关信息...... 在内部，它在自己的控制器中实现所有必需的操作（用于基本渲染、用户操作响应等）。在内部，它在自己的控制器中处理视图中的模型状态持久性和模型状态恢复。

真实世界的仪表板页面（上下文、场景）示例：

页面同时显示类别和产品组件。 Products 组件显示当前所选类别的所有产品，因此必须提供外部接口（参数或其他东西）以从上下文中接收所选类别标识符。类别组件必须提供某种外部接口，以便上下文可以在所选类别发生变化时起作用，并为产品组件提供所选类别标识符。

从技术上讲，页面更新的通信方式主要通过 AJAX 进行，但如果没有 AJAX 也能做到这一点，那就更好了。

在 AJAX 的情况下，我想要解决方案，它使用服务器端控制器来决定和呈现应该在客户端更新的内容（JSON 或其他东西）。

我会不喜欢客户端脚本（客户端“喜欢”控制器）中的解决方案，该解决方案决定调用哪些操作以及更新页面的哪些部分 - 如上一段所述，必须决定通过服务器上的控制器。

重要提示：通过某种路由直接调用组件不一定能工作。

您通常如何实施所描述的系统？

【问题讨论】：

我在使用经典 ASP.Net Web 表单使用描述的类似组件构建复杂系统方面拥有丰富的经验。但是，我看不到如何在 MVC 中实现这种方法。 MVC 为您提供了极大的灵活性和显示的可重用性（html 渲染），但它完全忘记了行为 - 组件不仅仅是外观，它还包括组件的功能和允许您执行的操作（行为）。在 MVC 中，我知道如何重用视图（使其模块化），但我真的不知道如何实现可重用行为（现在，每当我使用组件时，我都会得到重复的代码）。

标签： asp.net-mvc asp.net-mvc-3 components modularity interaction

【解决方案1】：

我认为您需要调查实际项目并了解您需要使用什么方法。尝试以下项目，您可以找到许多最佳实践：

在这里您可以找到安全措施、服务、身份验证和许多有用的实施。

Kigg
http://www.nopcommerce.com/downloads.aspx
http://orchard.codeplex.com/

对我来说很难说它应该如何实施。最好编码一下。但是在你的情况下必须使用视图、控制器、服务和存储库的依赖注入。

【讨论】：

【解决方案2】：

每个控制器处理一个完整的用户-机器模式。也就是说，粗略地说，每个控制器负责编排用户案例的用户-机器交互（分析阶段的结果的用户-机器模式）。现在，如果您将“标准行为”放在将协调用户-机器交互模式的控制器中？这样，您将拥有“组件”，而无需协调它们的执行。在 Web 表单中，您的页面协调放置在其中的组件的执行……但在 Mvc 中，协调角色由控制器本身扮演。

您可以制作由控制器和视图组成的黑盒，只要它们各自负责整个用户-机器交互模式。这是一个“大组件”，而不是一个小的构建块，就像您实施 CMS 时的情况一样。

The Orchard CMS use a similar approach。但是，您所说的组件实际上是预定义的块，它们扮演着用户正在构建的网站的整个部分的角色。

【讨论】：

我想在某些场景（用例）中使用组件时将编程重点放在逻辑上。为什么每次使用组件时都必须重新实现所有 STANDARD 行为和交互逻辑？以具有过滤排序分页选择功能的网格为例。为什么每次我将 Grid 置于某些上下文（用例）中时，我必须重新发明描述网格内部状态的模型和对模型执行操作（使网格交互，具有行为）的内部逻辑？ ?在用例中，我只对当前选择感兴趣，而不是内部 - 如何做到这一点？
我了解您的问题。让我们更具体地谈谈网格。通常处理网格的逻辑被移到控制器中。这是错误的，网格是一个 UI 组件，所以我可以作为一个组件实现，但是其中没有包含控制器。它必须在输入中接收作为对象列表的一页数据并返回到控制器：1) 选择新页面 2) 新归档标准（作为 linq 表达式） 3) 新排序标准 4) 应用于数据的修改。我们可以实现所有这些组件...而不包括控制器。看看我的 Mvc Controls Toolkit。

【解决方案3】：

在我看来，您正在尝试实现与 web MVC 哲学不兼容的开箱即用的东西（MVC 的其他实现可能支持它）。

但是，如果您想在 ASP MVC 之上编写一个框架，我相信您可以实现您想要的。例如，通过使用区域，您可以实现对控制器、视图模型和视图的封装形式。

要为同一个主视图组合不同的区域，您可以编写具有自己的视图的前端控制器的等价物，该视图采用视图模型 - 该视图模型将由前端控制器启动以呈现来自不同区域的操作.

您可以通过在 ASP MVC 之上使用诸如 Backbone.js 之类的客户端框架来获得更多成果。

【讨论】：