我们的想法是构建一组可以集成(插入)到各种场景中的不同组件.
每个组件必须拥有自己的模型定义,控制器和视图.
组件不仅封装了视图,还封装了通过它的控制器的行为.
所有内部实现细节,模型,行为等……必须驻留在组件内部,
使组件变得独立,模块化 – 黑盒子.
这允许在不破坏使用组件的上下文中的任何内容的情况下更改组件.
运行组件的上下文不得对组件实现的内部细节做出任何假设.
另一方面,该组件不会对将使用它的上下文做出任何假设.
最后,组件必须提供与外界“通信”或“交互”的机制.除了内部,组件必须提供某种“外部”接口(如参数,数据,函数,事件……),这将允许组件集成到执行上下文中.
上下文(或场景)是包含组件的部分.
现在,上下文的基本挑战是管理组件之间的交互.
真实世界类别组件示例：
组件显示类别列表,并允许用户执行各种操作,如排序,分页和记录选择.
在内部,它有自己的模型,存储相关信息,如当前页面,排序,选择等…
在内部,它在其自己的控制器中实现所有必需的操作(用于基本渲染,用户操作响应等).
在内部,它处理视图中的模型状态持久性,并在其自己的控制器中处理模型状态恢复.
真实世界产品组件示例：
组件显示产品列表,并在其自己的控制器中处理模型状态恢复.
真实世界的仪表板页面(上下文,场景)示例：
页面显示类别和产品组件.
产品组件显示当前所选类别的所有产品,因此必须提供外部接口(参数或其他内容)以从上下文接收所选类别标识符.
类别组件必须提供某种外部接口,以便上下文可以在选定的类别更改时执行操作,并为产品组件提供选定的类别标识符.
从技术上讲,页面更新的通信方法主要是通过AJAX,但如果没有AJAX就可以实现,那就更好了.
在AJAX的情况下,我想要使用服务器端控制器的解决方案,它决定并呈现应该在客户端上更新的内容(JSON或其他东西).
我不喜欢客户端脚本(客户端“喜欢”控制器)中的解决方案,它决定要调用哪些操作以及要更新的页面部分 – 这在前一段中所述必须由服务器上的控制器决定.
您通常如何实施所描述的系统？
解决方法
现在,如果您将“标准行为”放在将协调用户 – 机器交互模式的控制器中？
这样,您将拥有“组件”而没有协调其执行的东西.
在Web表单中,您有一些页面可以协调放入其中的组件的执行…但是在Mvc中,协调员角色由控制器本身扮演.
您可以执行由控制器和视图组成的黑盒,只要它们中的每一个都负责整个用户 – 机器交互模式.这是一个“大组件”,不是一个小的构建块,因为实现CMS时就是这种情况.
The Orchard CMS use a similar approach.然而,您所谓的组件实际上是预定义的块,它们扮演着用户构建的网站的整个部分的角色.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
