在继续学习Model的实践经验之前，先思考一下Controller和View的实践原则在本次系统重构中的应用，我手上是一个后台管理系统(不是门户系统、不是具体业务系统)，通俗点讲就是给企业的运维人员用的一套系统。
后台运维系统最核心的就是导航菜单，一切工作从导航菜单开始，从UI结构上来讲就是典型的左右结构(左边导航右边操作区域)，主流的Web UI框架都有这种结构的Layout。再深入一层的核心是资源(这个不具备通用性，只是我手上现有系统的设计理念而已)：导航菜单是资源，企业组织结构是资源，用户是资源，权限是对资源的权限.....
粗略分析一下资源的获取流程及业务规则：
- 获取客户端参数，具体规则：参数可能是指定某类型的资源，也可能是指定某个具体的资源
- 根据参数找到所需要的资源，具体规则：根据参数从Model中获取数据，当然数据经过了权限过滤
- 返回给客户端
针对这种情况，相关的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，
