Microsoft 2013 新技术学习笔记 四

在继续学习Model的实践经验以前，先思考一下Controller和View的实践原则在本次系统重构中的应用，我手上是一个后台管理系统(不是门户系统、不是具体业务系统)，通俗点讲就是给企业的运维人员用的一套系统。

后台运维系统最核心的就是导航菜单，一切工做从导航菜单开始，从UI结构上来说就是典型的左右结构(左边导航右边操做区域)，主流的Web UI框架都有这种结构的Layout。再深刻一层的核心是资源(这个不具有通用性，只是我手上现有系统的设计理念而已)：导航菜单是资源，企业组织结构是资源，用户是资源，权限是对资源的权限.....

粗略分析一下资源的获取流程及业务规则：

1. 获取客户端参数，具体规则：参数多是指定某类型的资源，也多是指定某个具体的资源
2. 根据参数找到所须要的资源，具体规则：根据参数从Model中获取数据，固然数据通过了权限过滤
3. 返回给客户端

针对这种状况，相关的Controller的组织方案有不少：

• 不一样类型的资源创建不一样的Controller，在View中须要导航菜单的地方呼叫导航菜单的Controller，在View中须要组织结构的地方呼叫组织结构的Controller...
• 在单个Controller中经过不一样的Action来处理不一样类型的资源的访问。建立ResourceController，在其中建立CreateNavMenu、CreateUser、CreateOU等Action
• 在单个Controller中经过同一个Action来处理不一样类型的资源的访问。在ResourceController中用一个名称为Create的Action来处理不一样类型的资源的添加操做

后面两种方案尽管将业务流程放入Controller中，而业务流程中的具体业务规则放入Model中，但因为本系统中资源的类型是动态的，这两种方法会让Controller和View愈来愈不轻巧，或者Action个数愈来愈难以控制，或者Action内部的逻辑代码愈来愈复杂。第一种方案将业务流程实际上分散在"组织"(这里当动词用，即增长一种类型的资源时，要增长对应的Controller)中了，当资源的类型愈来愈多时，只要遵循这个"分散的规则"就能够优雅的增长新的功能，这不会减小代码量的增长，但能持续保持代码结构的清晰(这是从"管理"的角度来看这个结论而不是技术实现角度，对个人重构目标是合适的，若是你看到这篇文章，注意不要对你形成误导)。

所以创建如下区域规则：

    建立名称为Core的区域，用来组织纯粹的系统自身管理的Controller和View。本系统中后台管理的基础是资源，因此会有一个名称为ResourceController的控制器，

由于是后台管理，从UI结构上来说重构后仍是典型的左右结构(左边导航右边操做区域)，主流的Web UI框架都有这种结构的Layout，从这个角度出发，第一个Controller是导航菜单(定名为NavMenuController)，这个Controller就是单纯的返回Json类型的导航菜单数据，经过JQuery在View中接收并显示。而后会有身份验证及受权两个Controller，