J2EE design decisions [javaworld]

arsuner

J2EE design decisions
http://www.javaworld.com/javaworld/jw-01-2006/jw-0130-pojo.html
1.Business logic organization - 业务逻辑组织
Using a procedural design
非常简单的应用使用此方式,但随着业务规模的扩大,后续开发和维护会有问题.
Using an object-oriented design
业务逻辑层已经包含业务模型.
2.Encapsulating the business logic tier - 业务逻辑层封装
EJB session facade
使用Session Bean门面,粗粒度设计,但是依赖EJB容器.
POJO facade
使用POJO作为业务逻辑单元,是POJO facade提供服务的入口.
Exposed Domain Model pattern
譬如使用Spring管理所有的业务逻辑对象,通过spring进行引用.
3.Database access decisions - 持久层的设计
Using JDBC directly
费时费力,移植性差
Using iBATIS - addressed the problem of mapping between Java classes and SQL statements
完成了java类与sql的映射
to completely insulating the application from connections and prepared statements, iBATIS maps JavaBeans to SQL statements using XML descriptor files.
使用xml配置文件,把sql从java类中剥离出来.
iBATIS cannot address the overhead of developing and maintaining SQL or its lack of portability.
不能解决sql的维护和移植性的问题.

Using Spring's JDBC classes
使用了spring对jdbc的抽象,防止了jdbc的繁琐,代码可以更加优雅

Using a persistence framework
EJB 2
JDO
Hibernate

4.Concurrency in transactions - 并发事务控制

Handle concurrency in short transactions  短事务
Isolated database transactions 数据库事务隔离
Optimistic locking 乐观锁
Optimistic locking derives its name from the fact it assumes that concurrent updates are rare and that, instead of preventing them, the application detects and recovers from them.
An application can determine whether the UPDATE statement succeeded by checking the row count returned by PreparedStatement.executeUpdate(). If the row has been updated or deleted by another transaction, the application can roll back the transaction and start over.
Pessimistic locking 悲观锁
An alternative approach is to use pessimistic locking, which assumes that concurrent updates will occur and must be prevented.

Handle concurrency in long-running transactions 长事务
Optimistic Offline Lock pattern 乐观脱机锁
One option is to extend the optimistic locking mechanism described earlier and check in the final database transaction of the editing process that the data has not changed since it was first read. You can, for example, do this by using a version number column in the shared data's table. At the start of the editing process, the application stores the version number in the session state. Then, when the user saves their changes, the application makes sure that the saved version number matches the version number in the database

Pessimistic Offline Lock pattern 悲观脱机锁
The Pessimistic Offline Lock pattern handles concurrent updates across a sequence of database transactions by locking the shared data at the start of the editing process, which prevents other users from editing it. It is similar to the pessimistic locking mechanism described earlier except that the locks are implemented by the application rather than the database. Because only one user at a time is able to edit the shared data, they are guaranteed to be able to save their changes.  


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/13917/showart_74270.html