我眼中的J2EE |
| 时间：2014-05-04 10:03:48 来源：不详 作者：佚名 |
很长时间以来，我们一
来才明白J2EE的内涵要比ej
部分核心服务如JTA事务管
EJB仅仅是一个使用了JTA事
| 直被误导了，以为只有采用了ej
b广的多，是一套使用Java进行
理, 资源池，线程管理，还有jd
务管理、线程管理等J2EE基础服
| b技术的系统才算真正玩了ejb。后
企业级开发的技术规范，包含了大
bc,jsp,servlet等应用技术。而
务的分布式的组件标准。
|
Enterprise JavaBeans
developers will not have
details; multithreading;
| will make it easy to write
to understand low-level tra
resource pooling; and other
| applications. Application
nsaction and state management
complex low-level APIs.
|
| Declarative transaction management |
| Management of business objects |
记得一个人写文章说：
不用和那些服务器上的复杂
套接字,都见鬼去吧,我们只
| “EJB最大的诱人之处是她把应
的资源打交道了,什么数据库,什
需要专著于我们的商业逻辑的实
| 用程序和服务器分开了,我们再也
么进程,线程,什么安全权限,什么
现了。”
|
ejb已经出现5、6年时间了，很多J2E
有实现。
| E项目才也采用了ejb，sun所描述的美好前景也并没
|
1．Ejb规范本身是很复杂的，以至于
一起的,并没有减轻开发人员的负担。Ejb
机制如何，很多人都说不出ejb containe
| 没有多少开发人员去阅读他。Ejb总是与复杂联系在
container像一个黑盒子，ejb在里面如何运行的，
r是如何处理异常的，跟事务有什么联系。
|
Ejb的运行效率如何，
确的找出是程序甚至说哪条
| 瓶颈在什么地方，没有人知道。
SQL语句的原因，Oracle配置的
| （在Oracle中的调优我们可以很精
原因，操作系统和硬件的原因）。
|
2．Ejb的复杂意味着程序的开发效率
一个包中的ejb只能由一个人来开发,否则
。另外，拿entity bean来讲，每次想按
定义的一个select方法，然后编译发布，
| 是低的，以致于Jbuilder提供了图形化的设计工具(
合并比较麻烦) ,Xdoclet是另外一种辅助开发的方式
照不同的参数进行查询，都要去为entity bean重新
然后在业务逻辑中调用。
|
3．Ejb是在容器中执行
像比，他是一个需要其他环
| 的，意味着我们不能像一般的ja
境的重量级实现，单元测试是很
| vabean那样来对待他，与javabean
困难的。
|
4．关于entity bean,M
cache了，为什么还要去cac
是很小的）,仅仅是因为采
| arc fluery的文章中说Cache is
he entity bean（相对于enity
用了entity bean而看起来更面
| the king，可是数据库中已经有
bean的复杂性，数据的传输开销还
向对象吗。
|
Core j2ee patterns和
的。
| 一些所谓最佳实现的书都有相当
| 一部分内容来正确和简化使用ejb
|
| 一开始接触entity bean，感到的就是复杂，开发效率低，难以维护。 |
| 一般来讲，使用entity bean都是完成数据持久的功能。 |
后来看了hibernate,很简单,开始困
的理由，于是列举了具备的安全,事务,分
| 惑，总以为entity bean之所以存在，还是有他存在
布式计算等方面的优点。
|
后来还是开始怀疑entity bean存在
bean封装其他jdbc操作或者hibernate来
更像客观存在的domain model,而不是从
来更像真实的世界。
| 的必要,因为那些功能与优点都可以通过session
实现,想来想去entity bean唯一的不同就是构件了,
数据库里面取出来的数据，entity bean使对象看起
|
构件之所以存在，是与
调用业务逻辑和数据访问，
| 分布式计算分不开的。在一个系
不同的系统通过构件来完美结合
| 统中，你可以通过另外一个系统来
。
|
（其实torque也不错，
现or mapping的功能，而不
| 就是不能操作多个数据源，另外
是像hibernate那样通过xml文件
| 就是自己生成了相关java文件来实
来配置实现。）
|
| 我们需要分布式吗，Distribution and Scalability |
分布式意味着在网络之间进行协调调
。
| 用，意味着复杂，除非必要，就不要采用分布式技术
|
| 以前以为采用ejb，程序就是分布式的，就具备了可伸缩性。 |
抛开可以按功能来划分
不完全意味着分布式，只是
如何同步复制不同App Serv
，Session变量、数据库连
得Oracle的同步的资源都是
| 访问的系统，其实可伸缩性就表
很多分布式体系提供了Cluster
er之间的数据，而App Server是
接状态，我们如何复制呢。（好
内部的）。
| 明了是需要Cluster的（Cluster并
功能），而Cluster中的难点就是
与很多资源相连的，程序执行状态
不容易理解了Oracle RAC,而我觉
|
| 重量级与轻量级（ejb container vs spring） |
在公司论坛上看到一个
和文档拿出来秤，操过500
| 讨论heavyweight与lightweight
克就是heavyweight，否则就是l
| 的区别，如果说把一项技术的规范
ightweight。
|
| 似乎heavyweight总是与复杂性联系起来的。 |
我们所开发的系统并不是都是分布式
| 的，也并不都是那么复杂的，才会有spring的出现。
|
客观的说，ejb contai
。
| ner能够提供的功能，spring基
| 本上都能够以javabean的方式实现
|
区别还是前面说的ejb container是
转移对象间的耦合，把业务逻辑与安全、
| 一个构件的容器，而spring是一个对象的容器，一个
事务等相分离的轻量级解决方案。
|
Spring 最核心的部件
框架内部的组件按照一定的
| 就是它的Bean Container,在整
耦合度组装起来，对外提供一个
| 个框架中扮演了一个软总线，它使
服务的接口
|
如果开发一个需要跟多
ejb。
| 个系统交互运行的分布式系统还
| 是使用ejb吧， spring取代不了
|
对于大多数web应用，应该是一个不
据库），采用spring把。Spring+hiberna
比，spring的缺点就是没有规范。
| 需要访问其他系统的多层系统（即使可能访问多个数
te应该是一个比较好的组合，但和ejb container相
|
| j2ee系统的开发应该都是采用面向对象技术，关键是怎么用的问题。 |
很久以前，在重粒子空
我也深信不疑。
| 间的一篇文章里，把一切都描述
| 为对象，整个世界是那样的优美。
|
由于在我们的程序中，主要是针对数
自然。就查到了transaction script和do
| 据处理和流程处理的，才知道用对象来表达不是那么
main model的概念。
|
transaction script就是对表示层用
它系统的操作，把数据回传给表示层。
| 户输入的处理程序。包括验证和计算，存储，调用其
|
| domain model是所谓的域模型， 跟客观世界中的实体相对应。 |
transaction script属
，采用transaction script
能力，习惯了就可以能够组
domain model的，哪些不是
| 于结构性思维，直观一些，在系
也是一个不错的选择。domain m
织很复杂的逻辑，另外，我们必
，可以通过一些xxxManager或者
| 统中如果domain model不是很明显
odel属于oo思维，需要较强的抽象
须考虑哪些行为是通用的、属于
xxxController所实现的。
|
举一个例子，假如查看
查看是否进行了转帐，还是
是有他的用处的，可以说，
| 今天A银行到B银行的所有转帐记
从数据库中直接查询今天的转帐
所有的程序都要通过Transactio
| 录， 是列出A银行所有帐户对象来
记录直观。Transaction script还
n script来组织，程度不同而已。
|
这个世界，除了对象，还是有对象间
同，就可以从不同的角度来组织系统，不
案所记录他一生的活动是什么，数据，是
去问这个人。
| 的关系、行为规则和记录（数据）的，观察的角度不
一定需要用对象来表示。比如一个人是一个对象，档
我们关注的一个方面，我们来查档案就够了，而不用
|
在网上很多文章中，都会提到把系统
化的手段而已。
| 想象成一个完美的oo世界，而是db只不过是一个持久
|
| 我一直认为db也是一个完整的世界，能够做很多事情，特别是在效率方案。 |
所谓采用oo和j2ee的系
用。
| 统，模拟现实世界，注重对象间
| 的行为和关系，比较适合oltp的应
|
而db则是从数据角度来
别是在大批量数据处理和长
实现一般要比oo语言要高效
| 进行关注一个系统的，没有oo那
事务处理的时候有自己的优势。
，只是从大的方向来讲有它自己
| 么复杂的关系，处理效率很高，特
在不存在明显错误的前提下，db的
的处理范围。
|
你有多少系统是需要从
还是不错的选择。
| 不同数据库之间移植的，必要的
| 时候，在j2ee方案中采用些db技术
|
C/s结构下，在pb程序
库等一系列功能，你专心考
| 中，一个datawindow几乎可以从
虑业务实现就可以了。
| 界面交互、数据绑定以及访问数据
|
在多层结构的程序中，
自己来实现，仅仅在数据方
的名词。
| 这种好日子一去不复返了，因为
面，就出现了vo， dto，po，de
| 分层，属于接口性质的细节要靠你
tached po，domain model等众多
|
不同的层专注于不同的功能，对于界
的数据用vo来表示，在网络传输中又用到
| 面展现，在struts中有actionform用于显示，业务层
了dto（特殊的vo），数据保存又用到了po了。
|
在这种情况下，数据的
全一致，不完全一致的内容
，要么在业务层从新query
次进行查询更新。效率很低
| 完整性是一个很麻烦的问题，假
在页面生成的时候就丢失了，要
数据到vo进行更新，如果业务层
，而且容易出错。
| 如actionform可能和vo的数据不完
么把vo缓存起来在需要时进行更新
是单独的而且持久层是ejb还要再
|
在hibernate中出现det
使用，最后再传递回业务层
对象，甚至可以在界面中调
load的依赖对象，就不是那
的。
| ached po，可以当成vo,po来用
进行业务操作和保存。由于deta
用detached po的逻辑。缺点就
么好玩了，这种情况应该是可以
| ，也可以把数据传送到前台界面来
ched po可以是带有业务逻辑的域
是如果detached po中存在lazy
根据编程时的具体情况来选择避免
|
Domain model,是一个特殊的值对象
据，实现业务逻辑，并把数据进行保存。
处理，只是从分散的位置集中到一处了。
| ，带有业务逻辑和持久功能。他接受和加工客户端数
Domain model中数据完整性和持久问题还是要在内部
|
总之，在多层结构中没
案。总是有很多东西要自己
| 有一种方案能够像pb中的datawi
处理。
| ndow一样智能和完美的数据处理方
|
另外，web页面是一个无状态的简单
javascript+xml）来处理，每个动作都要
堪忍受。Pb和delphi的那种年代真是一去
| 页面，界面上的只有通过javascript（
提交给服务器来操作后返回显示，很多时候简直是不
不复返了。
|
| 不知道以后jsf如何，因为客户端还是可以做很多东西的。 |
就servlet来说，
对于Action。除了那些开源
说了。
| 也可以用作页面显示,没有什么
方案，界面一般都是jsp来做，
| 意义，一般可以用作流程扭转，相
直观简单。xml我没有弄过，就不
|
现在很少有人直接在js
来表示，根据不同的动作来
把controller和model结合
| p页面里面嵌入业务逻辑和数据
调用不同的业务逻辑。唯一有点
表示，很方便和新颖，只是从来
| 库访问代码了，都会用controller
意外的是看到webwork2中用action
就没有用过webwork2。
|
目前的mvc结构，为程序带来了灵活
需要去解决所带来的问题。
| 和复用的功能，但是分层毕竟是有代价的，很多时候
|
| J2EE体系已经比较成熟了，也总是在修修补补中不断前进。 |
|
|
|
|
