界面层与业务逻辑层分离

转自：http://blog.csdn.net/sasoritattoo/article/details/8005331

分类： 架构学习 2012-09-21 18:10 483人阅读 评论(0) 收藏 举报

数据库 mvc 微软

看到这里的帖子http://topic.csdn.net/u/20080822/11/83fac755-6074-4994-bd7d-506541cd4e89.html，其中有个人的回答很受益

“

谈一下我的观点：

首先，对你的问题，我觉得是两个问题搅在一起了，还是分开来讲比较好。

一个问题是软件分层和耦合的问题。

另一个问题是如何划分业务逻辑和界面的问题。

首先，软件设计为什么要分层，这是为了应对软件需求的变化来考虑的，软件需求总是在变的，但变化是有规律的，不易变化的需求叫稳定需求，而易变的需求叫不稳定的需求。
而软件设计分层就是为了在不同的层次上应对这些稳定性不同的需求，在上层设计中响应不稳定的需求，而在下层设计中实现稳定的需求，而在分层后的设计中使得上层依赖下层，而不允许下层依赖上层，则可以使得应对大部分需求变化时对系统的修改最少，这就是软件分层的原理和原则。

在一般的MIS系统中，通常数据库结构是最稳定的，轻易不会修改，扩充是有可能的（除非在设计数据库时对用户的业务分析有重大误解），所以通常数据层放在最下层；而业务逻辑也相对稳定但会有变化，所以放在中间层；而最易变的则是表现层，今天说字太小看不清，明天又说字太大看不全，这个说灰底色难看，那个说白底色晃眼。所以放在最上层。

关于耦合，这个词在结构化设计中用得很多，在面向对象中，通常讲依赖关系。上层对下层的依赖（或者说强耦合）是理所当然的。比如说，通常应用程序是上层，而操作系统是下层，你能说你编一个应用程序不对操作系统耦合吗？但下层对上层则绝对不能有依赖（或者说零耦合）。没听说过谁为了自己的应用程序能运行而要求微软修改操作系统的。

做到这样，你的系统就达到目的了，而完全没有必要为上层对下层的依赖（或者说强耦合）而耿耿于怀。
但下层对上层依赖则是一定要避免的，对这要极其重视。

当然你可能会觉得有时会无法避免，如MVC模式（在RUP中叫Entity-Control-Interface模式）中，实体变化后，不是要调用界面层来改变显示吗，这不就是下层依赖上层了吗？

是的，对于这样的逆向依赖，在你设计用例实现过程中没有必要考虑，在进行完初步的设计以后，再统一进行逆向依赖的反转。在面向对象设计中有几个反转这种依赖的手段，在下层定义事件（或消息）由上层来订阅是一种手段，在下层定义接口或抽象类，上层来实现该接口或继承这个抽象类也是一种手段。只要你做到不存在下层对上层的依赖，那么你的系统分层设计的目的就达到了。


关于如何划分业务逻辑和界面的问题。
我觉得这是一个对客户需求的理解和分解的问题，以及对应这些分解后的需求放在哪一层实现的问题，也就是业务逻辑层的职责和界面层的职责划分问题，业务逻辑层的职责应该严格限制在对业务原语的实现上，而界面层的职责则是控制数据的展现形式和将用户的操作翻译或映射到业务原语上。但客户提出的直接需求往往会将这两方面一并提出，并且其中的业务原语往往是隐含的和不明确的，则需要我们在理解用户需求的情况下去分解出哪些是业务原语，哪些是界面操作。

呵呵，太抽象了，举个例吧，简单点，我们常见的用户管理问题，客户说：用户密码都用“*”显示，用户改密码时，输入一遍老密码，输入两遍新密码，当老密码正确且两个新密码相同则修改成功。
显然在这个需求中，用*显示密码是界面层的职责，但业务原语是什么呢？是判断老密码正确且新密码相同吗？不对，业务原语只是用户可以改密码，于是业务逻辑层只要开放一个方法认证当前用户并更改密码就可以了，至于输入两遍并校对相同则是界面层的事。

总之对需求要分析，从中提取出真正的业务原语，当然有时这条界限是很模糊的，是否能正确的识别出业务原语，就看每个人的分析能力和经验了。

”

另外看了《解剖PetShop》系列五 PetShop之业务逻辑层设计的文章也很受益。

拿以前做的一个电纸书的阅读pdf的项目简单分析了一下，如果当时能够这样了然的话，相信应该会写的更好。