选择Store procedure 还是 Application Server?
　

---

传统的client/server系统上, 大部分应用逻辑存于Stored procedure中, 优点是performance, 缺点是代码维护难. 而且几乎谈不上OOA/D和UML

n-tier系统发展后, 随着各种persistant management技术的发展(EntityEJB, O/R mapping, JDO etc.), 应用逻辑都可存于中间层, 对大部分软件公司来说, 这样带来的代码维护似乎更重要一些, performance的缺点随着数据库对prepared-statement的充分实现, 也在某些方面减弱了, 而且机器便宜了,performance 大不了可以用cluster来提高. 但是用Stored procedure对用户来说,performance方面还是有比较显著的差别的 (比如多个不同的SQL语句, 这样用prepared-statement的优势就不存在了).

很多用户对n-tiers还是不太能接受, 而且application-server对硬件要求也比较高, 多半是肯定要更换机器了. 特别对于那些想升级应用软件的传统用户, 大部分希望保留现有硬件, 再加上cluster的软/硬件都很贵, 他们一般都拒绝n-tier的结构.

那么要推广n-tiers architecture, 就应该有比较硬的数据来比较: 使用stored procedures 和 各种不同的persistant management技术(假设architecture和implementation充分考虑performance). 可是我遍查internet, 似乎都没有这样的数据. 因为大家(软件公司)都在说n-tier好. 也许实现很多更方便的功能, 但是根据我在银行的经验, 上面几乎没有人对n-tiers的performance有信心, 特别是内部开发的系统, 因为没有产品化的必要, 最后还是 unix processes (fork) + socket + stored procedures的体系结构. 然后client端用VB + Crystal report.

请问有没有大侠对这方面有研究, 指点迷津一下.

n-tier和design pattern是应对变化的，stored procedure技术是集中式的，提高效率的。各种技术的面向不同，应用的环境也不同，解决不同的问题。
技术没有好坏，只要用对地方就好。

 现在我们一个旧系统明显的问题是应对变化的能力不足.
　

---

该系统需要更新换代. 以后要和很多系统集成, 那些系统有的也在换代中. 原来的系统是用CLIENT/SERVER方式做的.

该系统对Performance要求还是比较高的, 但是由于要采用SYBASE做数据库, connection-pool和prepared-statement都没有. 假如解决应对变化能力为第一要务, 采用n-tier系统架构, connection-pool可以在某些Application server中找到, 但是没有prepared-statement对performance的影响还是比较大的, 而且某些操作需要多个SQL statements.

那么在细节设计的时候是否就应该考虑到这些操作, 不能完全用OO的, 对于某些复杂的数据库操作, 就必须打破OO的框架, 用stored procedure来实现.

这样的系统好像不适合: 先OO设计和实现, 然后再调performance的process. 因为如果设计的OO方法造成Object之间的联系太复杂, 在transition阶段, 要想对某几个Object打破用Stored procedure来实现逻辑, 并且不影响系统的其它方面, 似乎太难了.

以上我的想法对不对呢?

首先我们这个项目的钱已经下来, 足够重新投资.

其次, 如果使用原来的CLIENT/SERVER方式: VB/CrystalReport + SYBASE直接连接, 然后是结构化程序设计, 是肯定不能解决系统的应对变化能力不足的问题的.
　

我建议采用上述方案的原因如下:

1. 该系统更新后要适应全世界各地分公司的使用(欧洲, 北美, 亚洲), 近千个用户的实时使用, 因为使用过程中可能要不断的更新版本, 为了解决CLIENT端Deploy的问题, 几乎只有WEB和Java WEBstart类似的技术可以用, 而其中又以WEB完全没有deploy问题.

2. 用WEB, 基本只有J2EE 和 .NET选择. 3-tiers结构在所难免.

3. 数据库中心化, SYBASE11(可能会升级到12)是我们一直使用的数据库, 它的没有Connection pool和完全的SQL statement preparation 是人所共知的. 上面老板不想换数据库, 他们希望在PRODUCTION只有一个版本的数据库需要维护. 那么为了保证PERFORMANCE, 好像没有其它好办法.

也许是我经验不够, 但是目前这个问题(具体问题请看楼下我回SPIDE的帖子)好像必须用N-TIER.

如果我们有个好的Architect, 他能力很强, 能够组织很好的设计, 在设计时充分考虑Performance, 他很有责任心, 对于不熟练Design pattern的developer, 他能够做mentor的作用. 再比如对Performance采用下面我回lee_sure的帖子的方案, 是否还有问题?

您说的"能力"还包括什么呢? 或者对后期调整PERFORMANCE还有什么好的办法呢?

从我的经验来看, 假如一切能提到Application层进行CACHE的static data都在设计阶段考虑了(这种改动最好也不要再RUP的Transition阶段进行, 因为影响面太大). 后期的改动大多只能在最后2层之间: 比如用JDBC替代Entity EJB或者其它的Persistant Management. 不知道用JDO/Hibernate的系统是不是同样的指导方针.

关于robust，我认为mainframe是最健壮的，当然用cluster的mainframe更健壮。oo和n-tier和performance和robust是不同的概念，会有交叉。n-tier由于其程序本身的复杂程度，导致网络开销较大，性能是一个要注意的问题。对于我来讲oo不是java/c++，不是所有的业务必须用oo的语言实现。你可以用store procedure，那是一项可行的技术。
维护n-tier的代码有时比维护store procedure更难，由于n-tier代码分层，遇到贯串性的改动，你要改变所有层。:(
所以我觉得“活学活用”是关键。

现在很多人在做n-tier项目的时候都把performance tunning 放到最后(如果按照RUP,就是transition阶段). 前面设计和实现过程中几乎不考虑Performance, 而是尽量保持Object之间关系的清晰, 但是假如要用Stored procedure来提高性能, 就必须在某些地方打破OO, 这样只有在设计和实现过程中加以考虑, 而不能等到最后, 否则如果这种改动涉及面太大, 可能就没办法改了.

另外如何选择逻辑是否放在Stored procedure还是Application server的问题.
我认为除非需要多个不同的SQL语句完成的update操作,而且这个操作使用很频繁, 对它的Performance要求比较高, 才需要放在Stored procedure, 否则应该尽量在Application这一层实现.因为现在的Application server的CACHE功能都很不错, 不是经常需要UPDATE的东西最好都CACHE在前面.
另外一种观点是凡是对象(TABLE)关系复杂的东西都要放在Stored Procedure实现, 不管他们是被主要用来读还是写. 因为读的时候, 从库表中搜索, 利用数据库的机制效率高. (前面的观点是读的时候主要从CACHE读, 就算要搜索, 在应用层也可以实现效率高的算法.)
这2种观点哪个比较合理呢?

Performance是需求，要在分析和设计时考虑。
保持业务逻辑的清晰管理可以用oo来解决，用java/c++等来实现或混用procedure/c/汇编。保持模块（class）功能的单一可以认为在某个程度上就是oo的。而不是打破oo。
db的sga就是动态内容的cache，没有appserver的cache可以替代。我不知到有什么appserver有内容级cache的能力。用什么实现数据库访问，ejb/jdo/sql/procedure都可以，要看你的需要，都是符合oo的。
你提两种观点都是各自充分展示的优势，都是比较极端。你选择那一种可以说都是对的，也是错的。解决的方法我们的老祖宗已经讲得很清楚：“中庸”，不偏之谓中，不易之谓庸，...，中庸天下正道也。

再加上“如果我有足夠多足夠好的程序員，如果我有足夠好的開發經理，我有足夠的時間，我有足夠耐心的用戶，我有百折不撓的勇氣和百折不撓的團隊，並且我是一個有遠大目標的開發商，。。。”，那麽，你就選擇n-tier吧。當然，這是就一般而言，從你的問題來看，將n-tier和store procedure放一起做選擇，估計問題也難不到哪裏去。