还有关于耦合性过高过高的理论我有点异议，我觉得松耦合、代码重用是一种变成的优秀风格，不管是java、.net还是数据库编程。其实数据库变成也可以用过程和函数把一个个业务封装起来，而且如果按照erwin图上的关联来封装的话，那么业务逻辑的实现也是很优美的。

可能是行业差别，我们客户的业务是比较适合用存储过程来做。

Oracle的数据库功能够强了吧，连JVM都集成到Instance里面了，既然数据库本身都能跑JVM了，按照你的逻辑，再运行一个WebDB不就够了？还有什么必要花那么多钱开发Oracle9iAS？单独弄一个App Server出来？

IBM的DB2也是最强的数据库了，可是IBM同时也是最强的App Server厂商，如果光用DB2 ＋ Apache就够了话，IBM又何必开发Webshpere？

Sybase也不例外，如果所有逻辑都放到数据库里面，那么EAServer有何必去做呢？

而MS一方面不断在增加SQL Server数据库本身的业务处理能力，比如增加数据库的XML支持，另一方面还不是在大力发展 ASP.net？

>>数据库处理的逻辑完全是数据驱动的逻辑，
对于那些强调算法的逻辑，比如说电信计费，银行结算什
么的，非常适合，但是对于那些算法简单，但是步骤特别
烦琐的非常强调行业流程的商业型逻辑并不适合，甚至来
说，这样的业务，大部分情况下都是处理表的CRUD操作，
和多表之间关联的CRUD操作，你根本就没有什么store pr
ocedure可写的。这些业务需要的是需求模型驱动，而不是
数据模型驱动，你用数据驱动的模型是处理不来这些业务的。
<<
同意.
>>
况且把所有的逻辑都放在数据库里面实际上是牺牲了可移植
性，并且耦合性极高。
<<
hoho，牺牲了可移植性怎么了？耦合性极高怎么了？：）
这都是教科书上的话，给被灌输者一个概念，耦合性高的系统
不好。但教科书上很少深入提到在现实环境中耦合性高会造成
什么后果，有什么危害？有人可能会说耦合性高了可移植性不
好，耦合性高了组件无法重用等等。。我先问一句，你见过成
功的可重用的有商业价值的组件吗？（加个后缀 at china）
hoho,我没见过 at china. 原因是什么？细粒度的组件耦合性
低，但细粒度带来的就是组件的简单性，很难具备商业价值
（教科书上教的例子都是现在有一家公司在卖一个可以进行加
法的组件，它的功能是输入两个数，就能输出它们的和，我喷
。。。）
而粗粒度的组件实现功能复杂，可是功能复杂本身就是和实现
的应用软件环境的强耦合，（纯计算组件除外）

还是我说的那句话，时不时的抬头看看远处，看看目标，需要
移植吗？不需要吗？需要吗？需要松耦合和可移植性高
的前提是你ONLY提供应用软件！，要适应各种平台，各种系统。
而实际情况是绝大部分企业项目实施者是系统集成商！，这一
点很重要！，可能你不做商务，如果软件，系统软件，数据库
软件，硬件分开卖，根本挣不到钱（除非你去国外，国外对软
件价值认知度高），几乎所有大型项目都是集成商统一提供系
统所需的资源[包括漏油器]：），列表后off掉一定的折扣，
因此环境是可以自行决定的。耦合性高恰恰成为了优势，
整个系统是浑然一体的，密不可分的。
可移植性高？你就不怕局方自己给你移植了？：）
这是客观事实。我重申，这应该是每个做项目的人应该牢牢记
住的：在最短的时间内已最低的成本达到客户的要求，使企业
利益最大化，这就是软件项目的成功。

正所谓解决之道在于解道。：）
>>
对于很多ISV来说，软件产品不能只绑定到一个数据库上，
<<
为什么？only one足以。
>>
一旦软件业务小有修改，就是整个数据库层的大手术，甚至还要
波及到上层的调用代码的大面积修改，那就是很麻烦的事情了。
<<
我不理解，我们这里业务变化相当快[电信竞争越来越激烈：（]
业务修改只需要调整对应的存储过程ctr+enter，okle!
怎么会波及上层的调用代码？
中间层只需要一句调用call xxx procedure(???...);
太...太...省事了...
恰恰是用cxxx或hxxx才会有这样的麻烦，因为商务逻辑都在调
用代码的环境中。
>>
我是反对把所有的业务逻辑都放在数据库层的（实际上很多
业务型的项目，你也没有什么可往数据库层放的东西），应
该根据实际情况，那些算法复杂，数据处理密集的数据处理
逻辑适合放到数据库层，而流程复杂的，需求驱动的业务处
理逻辑适合由中间层来处理。
<<
没有什么可往数据库层放的东西?，项目有些小了。
我的经验是：算法复杂，数据处理密集的数据处理逻辑应用
一般都是流程复杂的，而流程复杂的未必算法复杂，数据处
理密集。
j2ee的强项不就是enterprais(不好意思，我英文不好，英文
不好汉语拼音补，顺便问前面那位Jevang大虾，既然能看懂
汉字，能不能回贴用汉字呀，我实在看不懂：），有空交流
交流。)企业级应用吗？

其实我是铁杆j2ee支持者，正因为支持，所以才更在意他的
不足之处，我希望有高手能批驳我的观点，从这种思想执行
的后果出发来评价如何不对，从而能使我提高，可到现在为
止，事实证明，活下来的系统集成商证明，这样的技术是
正确的，这样的技术能让企业活下去，挣到钱。at china.

我碰到过客户提出，我们早就购买了某某数据库软件运行在小型机上，我们不准备再花很多钱买硬件买数据库来跑你们的系统，希望你们的系统能在我们现在的数据库上跑。这时候你怎么办？你敢对客户说我们的数据库支持only one，你必须再多花几十万银子买硬件买数据库？还有的客户天生对某些数据库产品有排斥感，刚好你的应用软件only one支持的就是客户讨厌的数据库；还有的客户天生对某些数据库有癖好，非要指定某数据库不可。这些情况我都遇到过，要是都像你说的那么拽，我们就是only one支持数据库，就不支持别的数据库，那么生意都不要做了。当然如果你非要说我说的这些都是小项目，不值得一提，你做的那些几千万上亿的项目肯定都是only one的，我也无话可说，从你上面的帖子中来看，你做的是移动运营商的业务，可能只做only one的上亿业务，从来不做千万以下MultiDB的项目吧。

耦合性和颗粒度是两个概念，我强调的降低耦合性是分层，把不同的逻辑分层，需求修改限制在层内不扩散出去，这在层次结构清楚的中间层是很自然的事情，把什么东西都塞到store procedure里面，一改就得改整个数据库层？我也曾经做过数据处理密集的业务，那是广告投放的数据分析，库里面七八十个store procedure，一旦业务改变，数据库表要重新调整，那些凡是依赖表的store procedure统统修改一遍，然后再调用这些store procedure的store procedure也要至少重新编译一遍（Oracle数据库），一点点数据库表的修改，就要把整个相关联到的store procedure都检查一遍，这难道就是你说的ctrl+enter就可以OK的吗？

>>我先问一句，你见过成功的可重用的有商业价值的组件吗？（加个后缀 at china）hoho,我没见过 at china. <<

强调可重用不是为了卖商业组件赚钱的，而是你做一个行业时间长了，一直强调可重用性的开发，能够公司里面积累很多适合本行业的开发组件，这些才是公司技术积累下来的财富，如果公司开发什么软件都只想着紧耦合，only one，那么不论开发多少年，每开发一个新软件，永远是从头来过，没有一点积累，那么公司永远也不能上台阶，而是一直在低水平上重复。

从项目管理的角度来说，开发软件必须用最有把握，最保守，有过很多次成功实施经验的技术，不能唯技术论，为了采用新技术而使用新技术，你前面帖子提的那些采用了J2EE，结果项目失败的例子，是不能够证明你的中间层不适合做数据处理的论点的，那些项目失败的例子是项目管理的问题，在移动计费这样强调速度和实时的情况下，放弃在数据库里面处理数据，必然导致项目失败。从前我们做一个网络广告投放的项目，为了提高投放器的效率，都用的是C来写守护进程提高响应性能，然后C的守护进程给Java发消息，Java处理消息，而Oracle数据store procedure处理繁重的数据分析业务。

>可能你不做商务，如果软件，系统软件，数据库
>软件，硬件分开卖，根本挣不到钱

你可能商务做得也不太多，只见过捆绑销售的（想不道好的名词）。

很多大项目的系统软件是用户指定（或者是系统软件
厂商自己做关系），除非利润太薄，否则集成商
还是不管三七二十一接下来再说的。

我见过的采用捆绑销售方式的大多是功能比较独立的
系统，在我们所处的行业，趋势是提高可移植性，因为
用户的计算机环境不是前几年那样，一块荒地随便什么都
可以种了。

》这样的业务，大部分情况下都是处理表的CRUD操作，
和多表之间关联的CRUD操作

这句话没错啊，企业应用程序说到底是帮企业管资产、管人、
管钱财的，你想想这些位置传统上需要什么高深的知识吗？
映射到计算机系统也一样，最重要的是把数据关系搞清楚，
条理清晰地记录变化就可以了。就这一点说，OO对关系的
处理要比RDBMS强一些。

>>企业应用中，都是已数据为中心的<<

说到这里，我发现最大的分歧在哪里，你言必称“企业应用”，是不是不符合你的企业应用标准的项目就不在讨论之列呢？你先说说看你的“企业应用”标准是什么吧？合同金额在多大以上才能符合你的企业应用的标准，多少张数据库表才能符合你的企业应用标准？或者说你心目中什么复杂度的应用才够资格称得上企业应用？

对Oracle来说，数据库内建的对象支持是非常强的，你完全可以在Oracle里面做到较低的耦合性，但是你还能找到第2个这么强的数据库吗？如果客户说我们不用Oracle，我们是IBM的Partner，我们必须用DB2，是不是生意就不做了？（我碰到过这样的情况），其实这也和行业有关，有些行业是IBM的传统势力，客户要求你必须用DB2，有些行业是Oracle的传统势力，要求你用Oracle。总之下结论之前，先说明你的结论是适合于某个特定行业的，还是适合于某几个行业的。

首先我声明，我的目的是讨论，和大家共同进步，而不是争论。
>>
你可能商务做得也不太多，只见过捆绑销售的（想不道好的名词）。
<<
我以前做过sales，这种模式利润最大。
现在市面上的系统集成商（股份有限公司）均采用这种方式，分成模式也不错：）
题外话，和咱技术没有关系,hoho
>>
我发现最大的分歧在哪里，你言必称“企业应用”，是不是不符合你的
企业应用标准的项目就不在讨论之列呢？你先说说看你的“企业应用”
标准是什么吧？合同金额在多大以上才能符合你的企业应用的标准，
多少张数据库表才能符合你的企业应用标准？或者说你心目中什么复
杂度的应用才够资格称得上企业应用？
<<
。。。 。。。
我想你误会了，并不是我言必称企业应用。EJB全称是企业级java组件。
j2ee是企业级应用的解决方案。我在这里讨论是向各位学习的，有人
反对我的观点我很高兴，终于找到人教我了，我的目的不是表明我从
事了如何如何大的项目，有必要吗？
我想表达的主要意思是:
是否所有的企业级应用(for j2ee)关于数据库操作方面只能用hxxx或
cxxx？为什么不试试通过jdbc调用存储过程实现。

这个主题已经有120多条回复了，前面很多网友有用hxxx不爽的，有
用cxxx难受的，这里提到的方案可以给这些郁闷的网友第三种选择。
有选择真好，中国联通，CDMA...
职业病犯了... :)

希望大家继续讨论，共同进步。
顺便问大虾们一个问题，
我在jboss400dr2调试消息驱动bean,onMessage里面就是system.out.println("test message")而已，部署好了，
客户端发message时也成功，但是server端看不到显示，咋回事呀？

界面实现逻辑肯定是最好不和数据库相关的，放在应用服务器里最好，

数据表现逻辑还是可以放在数据库里,也可以用中间层。

核心商业逻辑基本上都是对数据的操作，是要求高效率高可靠性。我目前服务的行业特征来说，放在数据库比较好。

其实robbin的说法我是很同意的，而且很希望有一天可以做一个需要把逻辑都在中间成实现的项目，而且希望真的作成功。

但是
》》》》》》》》》》》》
强调的降低耦合性是分层，把不同的逻辑分层，需求修改限制在层内不扩散出去，这在层次结构清楚的中间层是很自然的事情，把什么东西都塞到store procedure里面，一改就得改整个数据库层？我也曾经做过数据处理密集的业务，那是广告投放的数据分析，库里面七八十个store procedure，一旦业务改变，数据库表要重新调整，那些凡是依赖表的store procedure统统修改一遍，然后再调用这些store procedure的store procedure也要至少重新编译一遍（Oracle数据库），一点点数据库表的修改，就要把整个相关联到的store procedure都检查一遍，这难道就是你说的ctrl+enter就可以OK的吗？
》》》》》》》》》》》》》》》》》》

我不同意用存贮过程就不能很好的分层和扩展。

其实把不同的逻辑分层在上边谈到的已经是分成三个层了核心商业逻辑、数据表现逻辑和界面实现逻辑。

再谈核心商业逻辑用数据库的实现，其实核心商业逻辑的逻辑内容还是可以分成一个个子业务，一层层子逻辑的。从表之间的关系就可以看出来，这些都可以作成松耦合的方式，从一个个最小的逻辑做起，一层层封装起来，如果你乐意，甚至可以把每一个表都包装起来，这样如果你因为需求变更需要修改表，那么你只要修改包装那个表的存贮过程就OK了，其他都程序都不必动。

再有数据表现逻辑，其实用视图就是很好的封装方法。我们最初的时候权限表全部都改完了，但是很多作好的程序要改就太麻烦。没有问题，我用新权限表通过视图来再现老权限表，所有的程序都不用改，以后权限改成什么样子都不怕，我只要修改一下视图就OK了... 一样可以方便的扩展。当然我并没有把数据表现逻辑都放在数据库里，不过我正再考虑以后是不是要这样做。

至于》》》
然后再调用这些store procedure的store procedure也要至少重新编译一遍（Oracle数据库），一点点数据库表的修改，就要把整个相关联到的store procedure都检查一遍
》》
我认为不是问题，因为从新编译吗，系统自动就完成了，你只需要泡一杯咖啡慢慢的欣赏一曲音乐。
我不知道你用什么工具写pl/sql，我用PLSQL Developer很方便，改一个存贮过程，不需要你再去手工编译它的调用者，而且存储过程也是可以在调用时自动编译的，虽然不推荐这样做。

=========================================

其实我觉得分层呀，对象呀虽然是在java上最盛行，但是这些编程思想并不是java的特权，其实任何语言只要遵循好的设计思想都可以作出来可扩展松耦合的程序。就象说j2ee不如asp.net一样，其实只要有时间，用j2ee同样可以作出一个构架来实现出asp.net构架实现的东西。我现在做java就有一些思想是来源于asp.net，而我现在写pl/sql就是按照模块化的思想来设计的，我的帐务系统从第二个城市割接到第一个城市只改了一个过程，就把很大不同的商业逻辑给支持进来了。

Oracle的确可以在某种程度上较好的降低耦合性，但是要看到的是store procedure 是紧密依赖表名和表字段的，再怎么分离也还是一种紧耦合，修改个store procedure也要一个个源代码去看。Java的interface机制就是松耦合，只暴露interface，interface下面的源代码根本就不需要去看。何况前面还说了，有客户就是不用Oracle，怎么办？

其实这个问题的本质在于，你认为一个商业系统是以什么为核心在运转的，如果你认为任何商业系统都是以数据处理为核心，是数据驱动模型，那么自然会认为在数据库内处理逻辑比较好，但是有很多商业系统它的数据模型根本就不复杂，更加没有什么高难度的算法可言，它的难度在于复杂的操作流程，这样的系统不应该以数据模型来驱动，而应该以需求来驱动，那么这样的业务适合放在中间层。

QuestSoft的TOAD适合做Oracle数据库的数据管理和数据维护，但是要说到开发，特别是写store procedure，还是推荐QuestSoft的另一个软件SQL Navigator，专门用来写store procedure的，开发功能比TOAD强得多。