J2EE应用开发中结合商业需求选择合理的架构

如果脱离商业需求，而单独的讨论技术本身的优势是不够的。各项技术都有产生的特定背景，其中很多都是来自工业需求而触动的。一般而言，企业信息系统(EIS)都要求自己稳定、安全、可靠、高效、便于维护。同时，各个企业信息系统都有自己独特的要求，可能有些时候需要考虑与原有遗留系统的集成，所以了解各个企业信息系统具体的商业需求对于整个系统的架构显得很关键。

比如，如果待开发的J2EE应用系统中使用到的数据大部分来自于外在数据源;而这些数据可能是通过JDBC直接从外在数据源导入到待开发的J2EE系统的Database中。对于这种情形，如果在开发过程中，仅仅使用JDBC来操作数据库，对于小强度(并发访问用户少、数据流量少)的情形，显然是比较合适的;但如果，并发访问用户较多、数据流量大，对Database层使用较为频繁的情形，则显得有些力不从心。因此，对于这种需求，我们可以考虑采用Entity Beans with Caches。打个比方，在JBoss 3.2.1中对于Entity Beans的Cache策略有多种，这时可以考虑使用，，即“Standard CMP 2.x EntityBean”，方式并采用“D”类型的commit-option来保证Entity Beans的内容与数据源的同步，并使得系统的性能得到大大改善(同直接使用JDBC相比)。其中，可以将一些Entity Beans设置为read-only，以改善性能。当然，在这里也可以采用其他一些O/R Mapping技术，比如TopLink。

再比如，考虑这样一种情形：如果待开发的企业信息系统使用到的数据都是由系统本身生成和操作的，则建议采用：CMP Entity Beans技术。Entity Beans给大家的印象很坏，这可能与EJB 1.1给大家留下的坏映象有关吧。但是，EJB 2.0(或者说2.1)得到了很大的改善，Local Interfaces、CMR、Read-Only、Session Fa?ade模式给Entity Beans注入了活力。当然，并发用户多、数据流量很大时才会体现出使用Entity Beans的优势。其中，有一点很关键：要注重Entity Beans技术的性能调优，各个应用服务器都有自己的一套性能调优方案。对于JBoss 3.2.1，配置文件standardjboss.xml提供了Entity Beans技术调优的入口。比如，Bean Lock策略的合理使用对于Entity Beans的调优就显得很重要。这样使得，我们可以更加关注于系统的商业逻辑，而不只是底层的Database(EJB调优处于EJB Container中，因此我们处在J2EE性能的高端，而不是底端，即Database层。同时，Database层的调优使得J2EE系统的数据库移植性大打折扣。)。

简而言之，要结合各个系统的特定需求和状况给出具体的技术架构方案，而不能孤单的论述技术本身的好坏。