JavaEE方向？迷惑

[养猪业未来发展方向探讨]埃菲社20xx年4月15日从巴黎发出的一则消息称：联合国教科文组织发表了由400位专家起草的一份报告，题为“对于知识、科学和技术在农业发展中作用的国际评价”。这篇短文对我国当...+阅读

1。 Java EE有两个方向，一个是开源框架方向另一个是EJB方向。两个方向没有本质区别，知识使用的框架不一样。一般使用的是开源框架方向的，比如使用struts、hibernate、spring、struts2等，一般学习Java EE都是说这个。 EJB由于比较难学，而且开发效率低、部署繁杂，使用较少，但在部分分布式的场合需要。2。使用Java EE开发的产品常见的就是什么什么系统之类，比如人事管理系统、工资管理系统。在学校的话就是选课系统、学生管理系统之类的。这些都叫做企业级应用，应为企业中会有一大堆繁杂的业务逻辑处理，这时就需要使用Java EE来完成任务。这些产品可以是基于客户端的，但更常见的是使用网页的形式。3。 Java EE就是用于企业级应用，就是我上面说的各种管理系统。Javascript与Java完全没有任何关系。

Javascript只是一个浏览器端显示用的语言，而且基本上已经是使用成熟的Ajax框架来代替原始的Js。如果说有联系的话，学习jquery等基于js的Ajax框架会对JavaEE项目起到帮助。学习Java EE需要Java语言的基础。

J2EE业务逻辑和数据库访问决策是什么

务逻辑和数据库访问决策这里有2种完全不同的方法来设计JAVA企业程序，其中一种选择是采用标准EJB2实现途径（approach）。我更愿意称这种方法为重量级实现途径，当你使用重量级实现途径时你需要用会话beans(session bean)和消息驱动 beans(message-driven bean)去实现业务逻辑。你也可以使用DAOs(data access object)或者实体bean去访问业务逻辑另外一种选择是使用POJOs 和轻量级构架，这种方式我称为POJO实现途径。当使用POJOs实现途径时，你的业务逻辑完全由POJO来实现。你可以使用持久型构架又叫做对象/关系映射构架（a。 k。a=also know as ）例如Hibernate 或者 JDO来访问数据库，再用Spring AOP（面向层面编程）来提供企业服务，比如事务管理和安全。 EJB3由于融合了POJOs和其他一些轻量级概念，所以对两者（指轻量级和重考锻揪叮┑那�分不是很清楚。

举个例子，POJO中的实体bean既可以再EJB容器内运行，也可以再EJB容器外运行，然而POJOs中的会话bean和消息驱动bean仍然有重量级的行为，因为他们只能在EJB容器内部运行。所以，显而易见的，EJB3既是重量级的又有POJO的特性。 EJB3中的实体bean是轻量级实现途径中的一部分。在开发过程中，首要的是从各种各样的设计中选择到底采用重量级实现途径还是采用POJO实现途径。决策可以影响程序的几个方面，包括业务逻辑结构和数据访问机制。为了帮助从两种实现途径中择其一，来看这张典型的企业应用程序结构图，结构图在图示1中，而且在设计过程中就必须判断到底使用那种策略。 Figure 1。 A typical application architecture and the key business logic and database access design decisions。程序由网络基本表示层、业务层、持久层组成。

网络基本表示层负责HTTP请和为一般的浏览器客户端、XML和其他的胖体客户端生成HTML，比如为Ajax基本客户端生成HTML。业务层被表示层调用，用来实现程序业务逻辑。持久层被业务逻辑层用来访问外部数据源，比如数据库和其他程序。表示层的设计不在本篇文章讨论之内，来看图表的其他部分，我们需要决定业务层结构的接口，这个接口是提供给表示层以及其他客户端的。而且还需要决定怎样访问能供多个程序访问的数据库。我们还必须决定如何处理短期事务处理事务和长期事务处理事务的并发问题。这些加起来一共有5种决策。每种决策都是要设计者来制定，为了能看懂演示图（big picture）要每个开发者也都了解这些策略。这些决策直接决定程序业务和表示层设计的特点。

当然，还要决定一些其他很重要的决策。比如业务处理（transactions）、安全问题、缓存问题以及如何整合程序，但是关于这些问题通常在其他文献中讨论在图表1中显示的五种决策，每种决策都有多种选择。每种选择根据它要解决的实际问题都有相应的优缺点。后续章节中，你会发现每种决策针对一个或多个领域时，在功能性、易开发性、可维护性和可用性方面有不同的平衡点。尽管我是POJO实现途径的超级大FANS，但是仍然需要了解其优缺点，以便于为你的程序做最好的选择下面我们来了解一下每种决策的大纲和其选项。决策1：组织业务逻辑现在，很多的注意力都集中在某项技术的优点和缺点，尽管这很重要，但是在本质上你需要了解如何建构你的业务逻辑。如果不考虑如何组织就去写代码是非常简单的。

例如，为一个会话BEAN添加代码要比在域模式（domain model。 : An object model of the domain that incorporates both behavior and data。）中判断应该添加那种新特性要简单的多。理论上你仍然需要刻意的为你的软件设计最合适的业务逻辑。毕竟我相信你有过修改别人垃圾结构代码的惨痛经验关键的决策是：到底应该用面向对象的实现途径还是面向过程的实现途径来实现你的程序。这个不是关于技术的决策，但是你技术上的决策可以潜在的约束你的业务逻辑的组织结构。采用EJB2技术，有利于面向过程设计，然而POJOs和轻量级构架可以让你为特殊的程序选择最好的实现途径采用过程式设计虽然我是一个面向对象实现途径（指前文的使用POJO和LIGHTFRAMEWORK）的倡导者，但是有些情况下面向对象实现途径有些大材小用，比如你只想实现一个非常简单的业务逻辑。

而且，有时候，面向对象实现途径不太可行-―比如，你没有持久层构架来将你的对象映射到数据库中，在这种情况下，更好的方法是编写面向过程的代码，而且采用Martin Fowler称作事务脚本（Transaction Script）的设计模式，要比采用面向对象实现途径设计要好，因为你只需要写一个方法来调用事务处理脚本去处理表示层的请。采种这种实现途径的一个很重要的特点是，用于实现某种行为的类和数据存储区是分开的。在EJB2的应用程序中，这种方式的业务逻辑和图表2中的设计是非常相似的。这种设计的核心全都集中在EJB或者POJO的行为上，因为他们实现了事务脚本，并且还操作那些 “哑”对象数据（因为他们只拥有很少的行为，大部分都是数据）。因为大部分的行为都集中在少量的大型类上，所以代码会变的很难理解与...

文档摘要J2EEPersistence

short term read lock / long term write lock Optimistic Locking : version column Pessimistic Locking : create a transaction to obtain long term lock Lock Modes : OPTIMISTIC : Obtain an optimistic read lock for all entities with version attrshort term read lock / long term write lockOptimistic Locking: version columnPessimistic Locking: create a transaction to obtain long term lockLock Modes:OPTIMISTIC: Obtain an optimistic read lock for all entities with version attributes。 OPTIMISTIC_FORCE_INCREMENT: Obtain an optimistic read lock for all entities with version attributes, andincrement the version attribute value。 READ: OPTIMISTIC。WRITE: OPTIMISTIC_FORCE_INCREMENT。PESSIMISTIC_READ: immediately obtain a long-term read lock on the data toprevent the data beingmodified or deleted。 Other transactions may read the data while the lock is maintained, but not modify or delete the data。PESSIMISTIC_WRITE: immediately obtain a long-term write lock on the data toprevent the data beingread, modified ordeleted。

PESSIMISTIC_FORCE_INCREMENT: immediately obtain a long-term lock on the data toprevent the data beingmodified or deleted, and increment the version attribute value。 NONE: no additional locking。Question:How to choose which mode to use?。

开发J2EE应用应遵循哪些原则

1。结合商业需选择合理的架构如果脱离商业需，而单独的讨论技术本身的优势是不够的。各项技术都有产生的特定背景，其中很多都是来自工业需而触动的。一般而言，企业信息系统（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系统的数据库移植性大打折扣。)。简而言之，要结合各个系统的特定需和状况给出具体的技术架构方案，而不能孤单的论述技术本身的好坏。 2。 Framework的合理选用设计模式在J2EE应用系统中扮演着重要的角色。

因此，有一个问题摆在大家面前，是自己来实现具体的设计模式，还是借助于Third-party Framework。如果贵公司不大，或者说公司不想在J2EE基础应用Framework投入很多精力，选用现有的较为成熟的、稳定、与现有J2EE Specification兼容的技术框架会比较明智。一般而言，Framework本身，或者说J2EE平台本身都是实现并优化了具体的设计模式、规则，比如业务代理、Service Locator（包括Web Tier和EJB Tier各自的服务定位器，起到统一管理有限资源、Cache相关资源的作用，便于系统移植）、Front Controller、DAO等等。现有的J2EE Framework比较丰富。