[讨论] 业务逻辑分离问题

[cobi]

我们在做数据库应用的时候，最烦恼的事情应该算是如何对付业务逻辑了。按照教科书或者一些业界高人的提法，业务逻辑（或者叫企业逻辑）不应该放在客户端处理，特别是现在三层结构出现了，其中的中间层就是要处理业务逻辑的。

不过我在实践中一直为如何把业务逻辑进行分离感到头疼。毕竟在C/S结构下，很多企业逻辑我们都是写成函数或过程的样子供程序调用。而且他们的位置极有可能是放在数据输入过程中进行判断。如果要把他们放到中间层处理的话，那么可以触发这些函数的话就只能用dataset控件自带的数据操作事件，可共活动的空间太少了，而且也不一定符合业务的要求。因此特意请问各位，有没有很好的解决方案。

另外一个问题就是有关三层下如何取用数据。业界高人如李维都提到要尽量减少网络的roundtrip，但是这个真的可以实现吗？简单的象打开一张表，是全部把数据取回来呢？还是只取部分呢？我们的代码中如何对这些进行控制呢？希望有这方面经验的朋友可以给点提示，你们在应用中是如何解决这个问题的。

如果有资料可以提供的，请email到[e-mail]，谢谢！

[yuanjunjing]

接贴：catthunder(catthunder)

有兴趣讨论一下三层模式开发的团队分工问题.
http://www.csdn.net/expert/topic/979/979647.xml?temp=.6128351

[freevc]

up!
继续

[dreamyyuan]

up

[fxcken]

对于把业务逻辑和UI进行分离:我想这要取决你的分析和设计,如果你的分析是OOP的，你的设计是OOD的,那么业务逻辑和UI的分析是很简单的,用三层来做也很好办,比如现在流行的MVC模式的开发jsp/servlet+javabean/ejb+database就能很好实现,;但是如果你的分析和设计做得还是过去的面向过程开发的那一套:模块划分+函数调用,那再好的程序员也无法做到把业务逻辑和UI进行分离,
所以一套很好的程序作品,首先是取决你的分析和设计人员,再就是优秀的程序员来编码实现.最后是负责的测试。

对于有关三层下如何取用数据:李维曾经说过超过1000条记录的数据集合就不要放到前台用户界面上显示,我建议分段、分批处理吧,如果显示的话，用条件限制取30％放到界面显示,否则就显示数据的问题你的客户就要你死得很惨:因为他们无法忍受数据像蜗牛一样显示出来.

[cobi]

请有经验的人士继续给出意见，谢谢

[双手托天理三焦]

有这么个团队做过三层结构（二年前）
结构上太理论化，放在后台中间层处理。
结果：（系统运行三个月后）
1。客户端无论如何都很闲，但必须等待。
2。服务一提交，服务器CPU就100%满负荷。
检讨：
其实很多处理放在数据库层处理效率非常好（不是中间层）
通常二层与三层都可以（二层维护是较困难些）

[男人看胆]

踩个脚印。

[blazingfire]

c/s都搞不定呀，
b/s不知为何物

[wmm1977]

我们的后台是用JAVA开发的，我现在刚开始（还没开始）搞3层，以前都是C/S，我个人感觉3层还是挺好的，起码一个单位，开发3层的比普通C/S的钱要多一点，

[jollyant2001]

up

[manprogram]

分布式开发是种很好的技术，我们这有用分布式开发做出来的程序，确实很不错。
但是我也有疑问：
1、把业务逻辑放到中间层，做成"瘦"客房端，这样与C/S结构中，把业务逻辑写到存储过程中有什么区别？只是减少了一个数据库连接。
2、MIDAS是不是一种可以独立开发分布式程序数据库的技术，还是一种必须与COM+或者CORBA配合开发分布式数据库程序的一种技术。COM+ 与CORBA不用MIDAS可以开发出分布式数据库程序吗？

[wyb716]

中间层要采用接口对象封装业务逻辑,这样会降低维护成本!!!

[dq]

很多人离了数据库就不知道怎么编程了，“数据”就是数据，何必非“库”呢？
不反对使用数据库，但不应该让设计围着数据库转。
当然这样工作量和难度都加大了，但确是值得的。

退一步想，这么多人在老路上走不通，何不另辟奚径呢？
虽然荆棘丛生，总是要有人走的，只是愿意走的人太少，所以大部分人还是在原地打转。

[滚滚红尘中之沧海一粟]

本人做过三层也做过两层，但都不算成功，只能凑合用。经验是大量计算要放在客户端，为什么如此，因为如果放在服务器端，一个用户也许没有什么，如果1000个用户可就不同了。

[fz101thoreau]

我想了好长时间了，可是还是没有弄明白！！！

[pjy]

我觉得我们在讨论B/S和C/S，或者两层和三层时，应该理解他们的特点和主要解决的问题。
我觉得把界面和业务逻辑分离最大的好处是可重用，这一点不一定是在一个项目中体现，而且在一系列开发的项目中都可以重用或只修改业务逻辑。业务逻辑的设计我觉得要结合OOP的思想，把一堆C/S程序中的业务逻辑处理函数什么的搬到应用服务器中，我觉得没有体现三层的真正含义。
三层架构的提出，我觉得主要是为了大型的，用户数目很大的，业务特别负责甚至经常修改的项目，所以有负载均衡、客户易维护等特点。但我们国内更多的项目并不具备这些特点，所以会觉得标准的三层构架很理论，我觉得我们应该根据系统的特点来选择的两层或三层的技术。
象连接池这些技术，实际上是牺牲速度保证用户数，如果我们项目本身用户数不多，我觉得就可以保持数据库连接打开，以保障速度。
再象返回数据集也一样。一味减少返回数据集的记录数肯定会加大用户的操作时间，不管是让其输入检索条件还是通过翻页。（当然有些技术并没有这么大的副作用）
总之，我觉得三层架构有其先进性，关键看我们如何结合具体项目来取舍其中的技术。就象围棋，所有定式基本上都是利益均衡的，但结合具体的一盘棋就有不同的选择。我们就象那些下棋的人，还 没有水平发明定式，只能研究一下各有什么特点，该怎么用？
发表自己的拙见，如果不对，请别...哎呀，谁踢我:)

[2353939]

我认为不要过分拘泥于技术方面的理论，业务逻辑是不是要绝对的分离，这要看系

统的大小和不同的开发要求，各种因素要均衡的考虑，现在的计算机速度越来越

快，我们花了很多的精力做了一个运行效率很高的系统，说不定哪一天硬件一升

级，这方面的优势就会荡然无存，至于维护方面的问题，如果把业务逻辑完全的分

开到底是节约了维护成本还是更麻烦，我看还不得而知，从理论上来说分开似乎是

清爽了很多，但具体的实施的时候还要受开发工具的制约，我相信分布式开发是必

然的趋势，但要想得心应手的去开发分布式系统，我估计要在开发工具进行N次升级

之后，从目前来看我认为要尽量应用简单的技术作出还说得过去的系统，因为我们

是实践者，纯理论方面的问题就让那些研究开发工具的如李维等等的高手去做吧！

[axin1102]

为什么要用三层结构或中间件技术呢？
我近来也一直在思索这个问题。
到底是用存储过程还是在中间件里编写业务逻辑规则来实现所需的功能呢！
若是用存储过程和触发器来对数据进行更新修改的话，必须承认的一点是对于数据库服务器省去了编译SQL语句的过程，相对地提高了效率，但是这样做必修占用数据库服务器的资源！（比如：编写一个实现多表查询并进行大量计算的存储过程，那么查询和计算就必须占用去数据库服务器的资源）
若是采用中间件那么像上述的多表查询并进行大量计算的代码就可以在中间层即应用程序服务器中实现，把计算好的结果再更新回数据库服务器！那好这样肯定增加了应用程序服务器与数据库服务器之间的网络流量。但如果应用程序服务器与
数据库服务器之间的“距离”较近的话问题不是很大，反而可以利用多个应用程序服务器来减轻数据库服务器的负担同时也达到了负载均衡的功能！
若是要进行远距离传输的话，那就要小心了，依实际把握好分寸！可考虑分布式结构的数据库设计模式！
同时要注意应用程序服务器与客户端之间的服务接口要尽力做到稳定，不要轻易地改变，而且尽量只传输参数。若服务接口不定，这样会影响到客户端版本的分发与控制！
那么我在设计RMD时，除了在RMD中放置DataSetProvider之外就是在RMD中编写控制信息来调用OOD出来的对象的方法来完成控制。
那么OOD出来的对象我是用普通DataModule来实现的。
还有就是简单的查询我是用存储过程+触发器来实现的，涉及到复杂查询和计算的我都把它放在中间层实现。
以上是个人之见！望多提建议！！！
QQ：15618282。

[hongqi162]

学习！

[dreammaster]

我以前用java做过三层的电信系统，感觉系统最大的瓶颈是网络传输。整个系统是cs结构，前台是swing界面,中间是ibm websphere，后台用oracle.

建立了大量的value类,并使用前台，后台缓存技术，只要是存在的value类就可以精简后提交，在服务器端重新完全化（充分利用缓存在中间服务器的类）以减少网络流量.

上面有一们同仁说的不错，罗辑的划分是为了复用，或维护上的方便，但在实际中要权衡，有时将一些罗辑放在数据库还是可取的。前台大量的罗辑判断也是为了减少交互，降低瓶颈.