业务逻辑的定位: 向java走，还是向数据库走?

我遇到的情况与此类似：公司要做一个新产品的研发，涉及到比较复杂的流程控制。一方主张用xml+内存+数据库，另外一方支持xml+数据库。我赞成使用第一种方案，有了内存的数据结构，就不用将xml拆分成很多库表，反之将它映射到内存中，数据库只是作为历史数据库以及当前数据的备份。我不知道我的想法是否有问题？

POEAA讲了很多Pattern...
业务逻辑分很多种，一般的在线交易处理逻辑 service做最好。
批量处理，分析处理逻辑可以考虑存储过程。
建议能不用存储过程就不用。

[/b][b]引自 Expert One-on-One J2EE Design and Development

FYI

The use of stored procedures from J2EE applications is an area where we should be pragmatic, and avoid rigid positions. I feel that many J2EE developers' blanket rejection of stored procedures is a mistake. There are clear benefits in using stored procedures to implement persistence logic in some situations:

Stored procedures can handle updates spanning multiple database tables. Such updates are problematic with O/R mapping.

A more general form of the first point) Stored procedures can be used to hide the details of the RDBMS schema from Java code. Often there's no reason that Java business objects should know the structure of the database.

Round trips between the J2EE server and the database are likely to be slow. Using stored procedures can consolidate them in the same way in which we strive to consolidate remote calls in distributed J2EE applications to avoid network and invocation protocol overhead.

Stored procedures allow use of efficient RDBMS constructs. In some cases, this will lead to significantly higher performance and reduce load on the RDBMS.

Many data management problems can be solved much more easily using a database language such as PL/SQL than by issuing database commands from Java. It's a case of choosing the right tool for the job. I wouldn't consider using Perl in preference to Java to build a large application; neither would I waste my time and my employer's money by writing a text manipulation utility in Java if I could write it in Perl with a fraction of the effort.

There may be an investment in existing stored procedures that can be leveraged.

Stored procedures are easy to call from Java code, so using them tends to reduce, rather than increase, the complexity of J2EE applications.

Very few enterprises with existing IT shops have ported all their applications to J2EE, or are soon likely to. Hence persistence logic may be more useful in the RDBMS than in the J2EE server, if it can be used by other non J2EE applications (for example, custom reporting applications or in-house VB clients).

The danger in using stored procedures is the temptation to use them to implement business logic. This has many negative consequences, for example:

There is no single architectural tier that implements the application's business logic. Updates to business rules may involve changing both Java and database code.

The application's portability will reduce as stored procedures grow in complexity.

Two separate teams (J2EE and DBA) will share responsibility for business logic, raising the possibility of communication problems.

If we distinguish between persistence logic and business logic, using stored procedures will not break our architecture. Using a stored procedure is a good choice if it meets the following criteria:

The task cannot be accomplished simply using SQL (without a stored procedure). There is a higher overhead in invoking a stored procedure using JDBC than in running ordinary SQL, as well as greater complexity in the database.

The stored procedure can be viewed as a database-specific implementation of a simple Java interface.

It is concerned with persistence logic and not business logic and does not contain business rules that change frequently.

It produces a performance benefit.

The code of the stored procedure is not unduly complex. If a stored procedure is appropriate, part of the payoff will be a simpler implementation than could have been achieved in a Java object running within the J2EE server. Especially in an organization with DBA resources, 10 lines of PL/SQL will prove easier to maintain than 100 lines of Java, as such a size discrepancy would prove that PL/SQL was the right tool for the job.

Important  Do not use stored procedures to implement business logic. This should be done in Java business objects. However, stored procedures are a legitimate choice to implement some of the functionality of a DAO. There is no reason to reject use of stored procedures on design grounds.

似乎是在说javaeye上n年前曾引起各位大牛广泛讨论的 规则引擎+(业务)动态脚本 ?

这个依据你做的业务逻辑，比如说你用水晶报表做些东西的时候，在数据库里直接用存储过程比较合适。

脚本化是分析系统的特点，不适合应用系统，跑题了。

业务逻辑还是放在java当中好点。这和设计思想有关系，无论如果写大量的SQL逻辑在DB中也就代表业务逻辑的下移和固化。项目当中改变很多，应该多考虑些，放在java代码中要好的多，特别是可能添加的一些插入结果反馈的问题。

说存储过程不好维护的，基本都是没用过存储过程的，或者说没有用它做过严肃开发的。强大的存储过程语言一样可以实现多态，封装，接口抽象细节隐藏，高内聚低耦合，虽然不一定是用OO的方法。就看你对它的研究是否深入了。

全世界最复杂的基于数据库的两种产品：SAP和Oracle EBS，前者业务逻辑用ABAP开发，基本上是一种与数据库无关的存储过程语言；后者用Oracle PL/SQL开发。他们的规模复杂到你无法想象，但人家几十年也都维护得挺好的。反过来，目前还没有见哪种面向对象语言开发的系统，业务逻辑复杂度能跟它们是一个数量级的。

业务逻辑本身就是事务性的，对象建得再完美，还是要通过一段类似脚本的代码来初始化各种对象，操纵它们，调用它们的方法，来实现最终的功能。所以在这类应用中，面向过程是少不了的。也因此决定了，面向对象语言的优势很可能最终会被它引入的额外复杂度而抵消。

DBA贵还是高程贵?
而且还要是DBA级别的高程.
成本/收益
是一个公司活下来的唯一理由
我不知道SQL有多好
不过我知道.
对于存储过程有很多非业务性的问题等着你呢.
而现在的软件框架就是要大量的减少非业务性问题.

个人感觉,跟LZ的方向正好相反:应该是java和数据库都向着业务逻辑定位
从实现上讲,我的喜欢的作法是,
java用OOP的思想对业务逻辑封装
,数据库用就3大范式抽象,
两者之间尽量少拉耻,致于java从数据库里读写么,简单的直接写,复杂的则用数据库提供的procdure,但数据库的procedure是针对业务罗辑写而非java写,这样也方便日后跨平台