推荐一种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，就象你千里迢迢去找你的女友，你的女友一见面，说，你的领带打的不合格，回去再打吧，然后return false;扔下你象呆鸡一样，呵呵，虽然现在是电脑在干这活，也别对它太残忍了吧。 --- 评价：奇臭
   方法三：在你的Model中解决。其实我不说大伙也知道如何做了，呵呵
就是在真正交给人的EntityBean以前，在你的Model中将所有的valid都完成，你一见你的女友就只要kiss就成，而且和上边文章的第二、三种模式结合，比较好



第二 真正的封装

唉，打字有点累了，下次吧

//顺便：这篇文章和重粒子空间的文章一样，可以转发，但请保持它的完整性和注明出处以及必须取得重粒子的允许

2001-4-11

签名：

老实和尚不老实




[ 转发帖子 回复此帖 相关帖子 跟随帖子 ]


--------------------------------------------------------------------------------

相关帖子：


你要推荐EJB，还是Entity Beans  - 【重粒子】 2001-4-10 16:53:27 [ID:628953 点击:13] (100 Bytes) (1)
呵呵，我试试，我的表述和组织能力不是很好 ^o^  - 【老实和尚】 2001-4-11 10:09:07 [ID:629540 点击:33] (3923 Bytes) (1)
COOOL！这篇文章不好，那什么叫好^o^  - 【重粒子】 2001-4-11 11:14:50 [ID:629650 点击:13] (183 Bytes) (0)

--------------------------------------------------------------------------------

回复：(注意：回复这个帖子没有积分，这是3天前的帖子)