 |
建站必读 |
 |
|
|
 |
|
 |
|
| |
| 当前位置：首页 -> 建站必读 -> .NET技术 |
|
推荐一种EJB设计模式 |
/**
* 此文从重粒子空间转而来，已经原作者的同意
* 在看此文前，请先看Sun的一篇文章
* http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/
*/
//----------------------------------------原文发下
呵呵，我试试，我的表述和组织能力不是很好 ^o^
--------------------------------------------------------------------------------
【老实和尚】 于 2001-4-11 10:09:07 加贴在 重粒子空间 ↑
/**
* 过一阵会忘记的倒可能不会，因为毕竟做得太多，但将它能写出来，倒是能将思* 路更清晰些，但真正让我动笔，却是因为重粒子相邀
*/
在这里肯定是 EntityBean了[无论是BMP还是CMP都是可行的，因为在这里已经不是讨论EntityBean居竟如何实现这一层，而是它如何面向它的Client端(一般是application,javaBean等)，给它的client端以什么方法去使用的问题]
题外话：由此而产生的其它好处是我始料未及的，这已经超出了上边的文章的所介绍的好处，这也是我为什么要推荐它的原因
上边这篇文章介绍了三种模式
第一种模式[Using Separate Methods to Access Individual Attributes]
就不用多说，一个EntityBean,你得到一个Remote Interface后想怎么就怎么，看起来很自由，但比如，你的 EntityBean有30个字段/属性，如果你想更新其中的18个字段（这种要求我想是很常见的），你不得不用你的Remote.setXXX()18次，这可是18次远程访问，除非你确定你的client端和你的server端是在同一个container中，否则即使你的client端和你的EntityBean在同一台机器，在同一个application内，它也是RemoteCall，因为对于container来说，它是Remote,照sun的说法，Remote Call是expensive，将加重你的server的负担，这我们能理解吧。
这种模式还有第二个更严重的弊端，就是Transaction不能保证，在你的client的一个方法中Remote.setXXX()18次，其中任何一次均可能发生错误而中断（如你的数据过长…），但你却无法保证它的事务Rollback，除非你手写代码来保证，如果你真这么做，我想bea公司的人会落泪，那可是20000美金的东东呵，被人束之高阁，所以，在clien端再写transaction是不可取的。
那我们如何解决它呢，用第二种模式Using a Value Object for All Attributes
将所有的字段抽象成一个对象
用一句话来描述它的，在上一种模式中，你是在你的client端分18次将你的属性set给EntityBean，而在这种模式你是在你的client端先将你的所有属性(30种)全设置好，已经构造了一个Model（就是你的EntityBean抽象出来的一个普通的类，如果不明白，看一下文章就应该知道了），在你的client端只要调用一个Remote方法，如Remote.updateMember(Model myModel),这个方法传进去的是一个完整的对象，而不是一个一个的属性，俗点说，就是"打包上传" ^o^，性能的好处就不说了，具体实现参考文章中有，也不多说
再来谈谈它的事务的保证，由于它在打包的过程中并没有真正去更改EntityBean(也就是不涉及DB的操作)，你交给EntityBean的是一个包，那么，在EntityBean的内部updateMember()方法中将此包的属性释放出来，如
public void updateMember(Model myModel){
xxx1 = myModel.getXXX1();
xxx2 = myModel.getXXX2();
……
}
我们知道，在一个EntityBean中要实现它的Transaction是很容易的，这也是Ejb的特点，CMP和BMP如何实现，不用我说了
文章还推荐了第三种模式Using Multiple Value Objects
其实是第二种模式的变种，就是你可以将你的18种属性抽象成一个Model，而不是30个全部属性，实现起来是一样的。
///~对文章的描述结束
//=========
讲讲我所发现的附加好处，从oo的角度来说，有点让人兴奋
第一 -- valid Check
我一直不推荐将EntityBean写得太过复杂，现在出来了个Model，好了，全在client端的，来吧，将它写复杂吧，全在它里边实现吧
试想，你的一个属性，如 price，显然是不能为 character的，那么，怎么来保证呢？有三种方法
方法一：在你的client端接收值时进行验证，如果void，return false;这是最一般的方法，有点臭；因为这使你的代码太无效，因为你可能要在3-5个地方进行同样的验证（你的price可不是只在一个地方要用的呵），copy--paste到第3次的时候，你可能已经对自己不满了吧 -- 评价：臭
方法二：在你的Ejb中进行验证，如果void,return fasle;
这种方法，解决了上一方法的弊端，因为你在Bean中写一次后，别的clien端不用再写，但它带来了第二个恶果，系统性能恶化（为什么？），试想，你一次一次的将你的price1、price2次给你的Bean去验证（这可是Remote Call），然后返回false，就象你千里迢迢去找你的女友，你的女友一见面，d |
| |
|
| |
本站关键词： |
|
|
|
|
 |
|
 |
|
