界面层与业务逻辑层分离独特的看法

liuzhong001 2008-08-22 11:20:56

如何将界面层与复杂的业务逻辑层分离开来呢？或者是分离开到一个什么样的程度算是不耦合？

请大家谈谈你们的看法~！

界面层与业务逻辑层的分离：

...全文

1063 26 打赏收藏转发到动态举报

写回复

用AI写文章

26 条回复

切换为时间正序

请发表友善的回复…

发表回复

Alan_Pisces 2008-09-08

打赏
举报

其实所有的低耦合,都是建立在良好的层次和结构划分的基础上的.
在这个基础上,降低耦合的方法主要就是借助第三方,比如接口,抽象多态等.

liuzhong001 2008-09-08

打赏
举报

很好！
up

xb_feng 2008-09-05

打赏
举报

谈一下我的观点：

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

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

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

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

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

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

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

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

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

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

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

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

prettyboy923 2008-09-02

打赏
举报

mark
学习

a123lm 2008-09-02

打赏
举报

[Quote=引用 4 楼 Fusuli 的回复:]
要做到低耦合，复杂的业务逻辑层要做到提供简单的调用接口，你可以参照一下设计模式里的“外观模式”，不管业务逻辑层多复杂，只提供简单的外观模式，界面层只和这个外观打交道
[/Quote]

liuzhong001 2008-09-01

打赏
举报

[Quote=引用 20 楼 wmxj2008 的回复:]
cool 学习了
[/Quote]

wmxj2008 2008-08-28

打赏
举报

cool 学习了

sorryworld 2008-08-27

打赏
举报

希望你看一下MVC开发模式。在里面的介绍会非常清楚。
我以前业务和界面分离的最基本方针就是，页面里面除了数据简单验证以外，没有任何代码。所有的业务处理代码都放到业务控制层。
以前我做程序的时候，采用的方式是3层结构方式，借鉴的是EJB的架构体系。
页面只做信息交互，不做任何业务处理。
Servlet或者构建业务Bean处理每张View（页面）提出的请求，然后调用EntityBean进行数据存储和查询。业务逻辑层并不负责数据库的交互，所有的数据交互都通过实体层进行处理。
实体层主要负责数据的添加修改删除查询功能，其他的业务单据逻辑处理它并不负责。对于数据库级的错误由此层捕获，然后传递到业务逻辑层，最后传递到View层。
如果你用Java开发系统建议采用Struts和Hibernate。（Spring也可以）
如果你用C#建议你用VS.net开发。
他们都提供了业务和展现分离的基本框架。

liuzhong001 2008-08-26

打赏
举报

[Quote=引用 15 楼 outh24 的回复:]
note,学习了。
[/Quote]

jdlsfl 2008-08-26

打赏
举报

举例比较难，要在实际的项目中体会实践

tobylee999 2008-08-26

打赏
举报

支持举例说明，不要搞空谈。

liuzhong001 2008-08-25

打赏
举报

en ,太好了！

outh24 2008-08-25

打赏
举报

note,学习了。

liuzhong001 2008-08-24

打赏
举报

up,
go on!

csgdseed 2008-08-24

打赏
举报

[Quote=引用 7 楼 elifefly 的回复:]
单纯泛泛而谈是不当的。

没有绝对的分层和完美的耦合的。

都是根据需求和实际。

[/Quote]

caimps 2008-08-24

打赏
举报

[Quote=引用 3 楼 Fusuli 的回复:]
我们一直强调的是“低耦合”，不是“不耦合”，不耦合肯定没办法运行啊
[/Quote]

w102272 2008-08-24

打赏
举报

数据库+应用服务器+C/S Client(实际上应该是Internet Client)
数据库+应用服务器+B/S WebServer（ASP or .NET or JSP...） + IE

w102272 2008-08-24

打赏
举报

我的做法是：
开发应用服务器，将业务逻辑全部放到中间件上去。将数据库放在中间件的后面。
然后对业务逻辑抽象出一组公用业务对象API，
可以透过TCP，SOAP方式去调用。以便支持前端的 C/S客户端，或者WebServer的网页程序(通过SOAP调用WebService方式)。

然后把界面(C/S的Form界面，或者B/S的网页界面)，作一个UI部分的整体。
实际上这里肯定包含部分预处理，尤其是C/S界面；B/S我认为只是手段比较烂(JS什么的)，只方便做发布类的事情
前台的C/S或B/S界面，就不区分UI和UI界面内的逻辑了（有时候也很难区分）。

这样大概构成了3层。实际结构如下：
-------------------------------------------------------
数据库+应用服务器+C/S Client(实际上应该是Internet Client)
+B/S WebServer + IE
-------------------------------------------------------
DB 逻辑核心 UI和弱关联的逻辑