Agile

Spring Framework 1.1 RC1 出来了

项目快完了，在设计的时候也算是用到了IoC吧，虽然没有用到Spring，但是用了一个properties文件作为简单的配置文件，把对象中不确定的属性写到这里，之后在主程序MainService里读取属性，构造对象，再把各对象设给相应的对象，说起来没有什么难度，但是这一天几乎都在那儿写代码，要是用Spring应该没有这么麻烦吧，虽然也要写配置文件，但是不用自己装配对象，唉！这应该就是浪费劳动力吧:)

虽然我极力推荐，但是上面说这么小的一个项目没必要搞得这么复杂，奇怪，小项目就不用考虑结构的设计了吗？只要完成功能就行了吗？而且经过分析，虽说这个小软件的功能就两个，但是考虑到的东西还是比较多的，没有清晰的层次，做出来的东西不知会像什么:)

 

好久没上Spring的网站了，今天上去发现它有了Eclipse的插件，下载下来装了试试，可能有一个项目会用到Spring，我的梦想终于快实现了。

IoC是一种趋势，我选择Spring;重构是一种趋势，我选择Eclipse:)

将近两周的时间，《Expert One-on-One J2EE Desing And Development》快看完了，好在后面的内容在工作中已经学习得差不多了，今天下午头儿给了新任务，只好把后面的放下了，忙完了再继续看。有机会一定买一本收藏起来。

以前总是认为Stateful Session Beans比Entity Bean要易用一些，性能也更好一些，但是作者认为应该更多的使用Stateless Session Beans而不是Stateful Session Beans，同时建议在下面的情况满足时才使用Stateful Session Beans:

o When a stateless interface would be unduly complex and would require the transport of excessive
amounts of user data across the network Sometimes attempting to model the EJB tier in terms of stateless interfaces results in excessive
complexity: for example, SLSB methods that require an unacceptable amount of session state to be passed with each invocation.

o When multiple client types require state to be handled in the same location, or even shared
For example, a SFSB might validly hold state on behalf of an applet and a servlet application.(However, such sharing normally occurs in persistent storage.)

o To handle clients that frequently connect and disconnect
In this, a typical scenario, if reliable preservation of state is vital, it must be held in the database.However, if an SFSB offers adequate reliability, the client may be able to store an SFSB handle and efficiently reconnect to the server at will.

o When scalability is not a major priority
Sometimes we don't need to consider the performance implications of clustering with stateful session beans - for example, if we're sure that an application will never run on more than one server. In this case, there's no need to complicate design by considering the impact of state replication (however, an HttpSession object is likely to be a simpler alternative in a web application).

Don't use the javax.ejb.SessionSynchronization interface for stateful session beans. This promotes poor application design, with remote clients of the EJB tier delimiting transactions, or the use of JTA for transaction management when EJB CMT would be a better option.

作者在第8章对于使用Ejb给出了以下指南:

o Don't use entity beans if your EJB container supports only EJB 1.1
Entity beans as specified in EJB 1.1 were inadequate to meet most real-world requirements.

o Use CMP, not BMP
The greater control over the management of persistence offered by BMP is largely illusory. BMP entity beans are much harder to develop and maintain than CMP entity beans, and usually deliver worse performance.

o Use ejbHome() methods to perform any aggregate operations required on your data
ejbHome () methods, which can act on multiple entities, help to escape the row-level access imposed by the entity bean model, which can otherwise prevent efficient RDBMS usage.

o Use fine-grained entity beans
The "Composite Entity" pattern, often recommended for EJB 1.1 development, is obsolete in EJB 2.0. Implementing coarse-grained entities requires a lot of work, and is likely to deliver a poor
return on investment. If fine-grained, EJB 2.0 style, entity beans don't meet your requirements, it's likely that use of entity beans is inappropriate.

o Don't put business logic in entity beans
Entity beans should contain only persistence logic. When using EJB, business logic should normally go in session beans.

o Investigate your EJB container's locking and caching options for entity beans
Whether or not entity beans are a viable option depends on the sophistication of your EJB container's support for them. How you structure your entity bean deployment may have a big
effect on your application's performance.

分布式应用：

o Never allow remote clients to access entity beans directly; mediate entity bean access through
session beans, using the Session Facade pattern If remote clients access entities directly, the result is usually excessive network traffic and unacceptable performance. When any components outside the EJB tier access entity beans directly (even within the same JVM), they arguably become too closely coupled to the data access strategy in use.

o Give entity beans local interfaces, not remote interfaces
Accessing entity beans through remote interfaces has proven too slow to be practical. Remote clients should use a session facade.

o Create Value Objects in session beans, not entity beans
As we discussed in Chapter 7, value objects are often related to use cases, and hence to business logic. Business logic should be in session beans, not entity beans.

I prefer to manage persistence from session beans, using an abstraction layer of DAOs comprising a persistence facade. This approach decouples business logic code from the details of any particular persistence model.

 

我越来越佩服作者了，今天看了关于使用ejb的建议，觉得很有价值，摘抄下来:

1.Don't use the Composite Entity pattern. In EJB 2.0, entity beans are best used for relatively fine-grained objects, using CMP.

2.Implement only persistence logic, not business logic, in entity beans.

3.It's good practice to set the transaction attribute on entity bean business methods to Mandatory in the ejb-jar .xml deployment descriptor. This helps to ensure that entity beans are used correctly, by causing calls without a transaction context to fail with a
javax.transaction.TransactionRequiredException. Transaction contexts
should be supplied by session beans.

4.Don't use entity beans with BMP. Use persistence from stateless session beans instead. Using BMP entity beans adds little value and much complexity,compared with performing data access in a layer of DAO.

5.In EJB 2.0 applications, never give entity beans remote interfaces. This ensures remote clients access entities through a layer of session beans implementing the application's use cases, minimizes the performance overhead of entity beans, and that we don't need to get and set properties on entities using a value object.

选择数据库驱动建模还是选择对象驱动建模，一直以来争吵不休，本书的作者作了如下选择，我觉得对我以后的开发很有帮助：

I recommend database-driven modeling. Object-driven modeling is seductive, but has real dangers. Its fundamental problem is that it ignores the facts that relational Databases are
(a) very complex applications; and (b) proven to work very well. It's naive and arrogant (a dangerous combination!) to assume that J2EE, in a few years of evolution, has delivered a superior solution to decades of database theory and practice.

在书中，通过比较得出了分布式程序并不像我们通常所认为得那样具有更好的可扩展性和健壮性，同时指出决定一个架构的可扩展性和健壮性的关键在于服务器端是否需要保持其状态，而不在于它是不是分布式的。

Distributed Applications and Scalability
A distributed application is not necessarily more scalable than one in which all components are collocated on each server. Only a distributed architecture with a stateful web tier and stateless business objects is inherently more scalable than a web application in which all components are collocated on each server.

Distributed Applications and Reliability
A distributed architecture is not necessarily more robust than a collocated architecture. An architecture using stateless business objects is the only way to ensure that a distributed architecture is more robust - and more scalable - than a collocated architecture.