五. Controller和Model中该有哪些东东

    因为VIEW中的逻辑比较简单，所以对系统复杂性的考虑基本上要重点放在Model中，而Controller是对业务流程的控制，其应该保持“代码清爽”。说是这么说，但实际进行项目开发时这两者之间的界线能这么清楚吗，答案是“尽量保（坚）持”。必定这是MVC的“特色”嘛。

    另外这里向大家推荐一个不错的方法"Robustness"，有了它您就可以很容易的找出那些系统方法要放在MODEL中，哪些该归入控制逻辑中了，该方法我在两年前的一篇文章中提到过，大家感兴趣的话可以看看这个链接, 采用[ICONIX] 方法实践BLOG设计之四 [健壮性分析] .其核心内容如下：

    实体对象(entity object):

    通常是来自域模型中的对象(也就是现实世界)，它常对应于数据库表和文件，这些数据表和文件中存储了执行用例所需的数据。有些实体对象是“临时”对象（如搜索结果），当用例结束后将消失。

    边界对象(boundary object)：

    参与者使用它来同系统交互，这通常包含窗口，屏幕，对话框和菜单。如果有GUI原型，将会知道许多主要的边界对象是什么。

    控制对象(control object):

    将边界对象和实体对象关联起来（通常被称为控制器，因为它们通常不是真正的对象），它包含了大部分应用逻辑，它们在用户和存储的数据之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略。这样修改只需要在这些对象中进行，而不会涉及到用户界面和数据库模式。控制器偶尔 (20%的时间内)也会是设计中的“真正对象”，但大部分时间内，控制器只是一个占位符，用于避免您遗漏用例要求的任何功能和系统行为。

    上面的三个对象分别对应Model, View, Controller.

    正如文中所说，该方法还提供了如下好处：

    1.它帮助您确保用例文本的正确性，且没有指定不合理或不可能的行为 (基于要使用的一组对象)，从而提供了健康性检查。

    2.帮助确保用例考虑了所有必需的分支流程，从而提供了完整性和正确性检查。

    3.让您能够(持续)发现对象，因为在域建模期间可能会遗漏一些对象， 而这些对象在绘制时序图时不易被发现，并且很可能正是它导致无法绘制时序图。

    4.缩小分析和设计的鸿沟，从而最终完成初步设计(关于初步设计复核会在下一篇中介绍)。

    六.MVC与MVP是否可以同时出现在一个SLN甚至一个项目中

    这一点我想谁说了都不算数，只有用户需求才是王道，用户使用在当前项目中实现某些特定功能，而该功能恰恰是MVC或MVP的用武之地，那就一个字：“用”。

    最后还要再说明一点：

    业务逻辑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，所以说一个系统来说，业务逻辑是无处不在的。View上的是显示逻辑，Controller上是流程控制逻辑)，Model上简直就是“逻辑大本营”了。

    使用 MVC 框架时我们要将“经常变化”的业务规则（位于Controller）和相对稳定的业务逻辑（位于Model）分离开，同时在Model层采用接口方式实现，以此来应对将来不断变化的业务需求。