首先感謝南老師!
??????在計(jì)算機(jī)里的有符號數(shù)，最高位的1用來表示負(fù)號，所以，用 0000 0001表示正1，1000 0001表示-1，確實(shí)對人來說很直觀。但其實(shí)，計(jì)算機(jī)里的數(shù)是用“補(bǔ)碼”表示的。其中正數(shù)的補(bǔ)碼就是原來的數(shù)（稱為原碼），而負(fù)數(shù)的補(bǔ)碼是這么算的，我用倒推的來說：
??????補(bǔ)碼 = 反碼 + 1
??????反碼 = 原碼按位取反（1變0，0變1）
??????所以，-1就是1取補(bǔ)碼，過程如下：
??????先取反 0000 0001 ---> 1111 1110?
??????然后加1得補(bǔ)碼： 1111 1110 + 1 = 1111 1111?
????（當(dāng)然這里為了方便，就取了8位，其實(shí)整數(shù)現(xiàn)在都是32位了，結(jié)果是32個1）。
?????現(xiàn)在，你知道如何計(jì)算-2了嗎？ 為什么要搞反碼，補(bǔ)碼這么個轉(zhuǎn)換呢？ 這個原因要說長就很長的，但簡單地講，這又是一個在人的直觀和機(jī)器的高效之間取一個平衡：
?????我們先來看一個10進(jìn)制的數(shù)運(yùn)算：
?????1 + (-1) = 0 //10進(jìn)制中，1加負(fù)1應(yīng)為0.
?????然后，假如用1000 0001來表示－1的話。按照計(jì)算機(jī)計(jì)算加法的規(guī)則，它是每位加的，結(jié)果是：
?????0000 0001 + 1000 0001 = 1000 0010??//-2
?????結(jié)果變成－2了，其中后面兩個0001 相加變成2，而前面的用于表示負(fù)號的1，被“繼承”下來了……顯然，原來計(jì)算機(jī)最直觀的（對人來說也很直觀的）算法，不靈了！怎么辦？痛苦
??? 但更痛苦的事還在0這個數(shù)上。按10進(jìn)制，0和-0可是完全相等的。但如果用二進(jìn)制，0000 0000 和 1000 0000 參加起運(yùn)算，可是完全不同。或許可以通過電路設(shè)計(jì)，來強(qiáng)制讓計(jì)算機(jī)去實(shí)現(xiàn)一個規(guī)則： 碰到1000 0000就先轉(zhuǎn)換為0000 0000。但可要知道加減法計(jì)算是計(jì)算機(jī)計(jì)算一切的基礎(chǔ)，如果從這最底層就必須有一個轉(zhuǎn)換會極大影響性能！何況前面那個問題也必須有個強(qiáng)制規(guī)則！規(guī)則最好越簡單越好，那就是規(guī)定前面的補(bǔ)碼轉(zhuǎn)換規(guī)則，這個轉(zhuǎn)換過程對于計(jì)算機(jī)來說很迅速的邏輯電路轉(zhuǎn)換。
??? 你看，第一個問題 1 ＋ （－1）
? ? 0000 0001 + 1111 1111 = 0000 0000?
????看明白這個計(jì)算過程嗎？其實(shí)就是最低位的兩個1相加后，造成每一位都進(jìn)位，最高位直接溢出（丟了）。如果你還算不清，就算算這個10進(jìn)制的：
????1 + 999 =??1000 (最高位1丟失，就成0了)
????然后是第二個問題，0的表示。如果您把0當(dāng)成正數(shù)，那么它是這樣表示的：
????0000 0000
????如果你當(dāng)它是負(fù)數(shù)，那么
????取反 1111 1111 ，再加1，以求補(bǔ) ，哈哈又成 0000 0000這回在邏輯上沒有錯誤了！明白了吧？當(dāng)補(bǔ)我在學(xué)習(xí)這一段知識時，只能說：高，實(shí)在高！ 想出補(bǔ)碼的前輩，真是高人啊。
This article is focused on which approach we should choose for unit testing against Struts action, I hope it will give you some help when you have question on how to do unit testing against the controller in MVC.
OK, let's begin!
In container? Mock objects?
There are two kinds of testing, one is in-container and the other is do testing with mock objects. Generally speaking, it was considered to be more really and truly unit testing when you do testing with mock objects, especially when you do testing against java source files which should be run in J2EE container, but as our code become complex which contain more layers, the controller(Struts) will have more depends on the other layer which may be EJB service or other business objects, so when you do unit testing against view layer(here is Struts), it will be a huge work for you to construct the mock objects and also it will have more source code changed as you apply mock objects in your source code, the following is a simply description which describe the classic three layers project, and also considerd to be the most common type of web based project.
e.g. the Struts action class first call the EJB factory to get an EJB service, and then ask this EJB service to do the work according to the business logic and return the value we need, with the value EJB service returned the action class can choose which page to redirect or do some other data processing ,this could be the classic three layers type, maybe the most common type project we used in our project.
Therefore, it may not be the best choice for every web based project to apply mock objects unit testing. In the case that Struts action class is close tied with your business object, in-container testing may be an alternate choice for you, because it save your time to write mock objects and the workload to apply the mock objects into your source files but supply the same testing resluts.
In-container testing sounds good, but when you do testing in this style, it first assume that the depended business service classes used in our Struts action must be verified, if the depended service classes have some defect that happen to be met when we run in-container testing, it will take more time to find which cause the error indeed.
But I think if we have a complete testing procedure, which cover the service layer and the controller, the service layer have already been verified properly, in-container testing is really the best choice for you to use for testing action class. For project in practice, the Struts action is more or less close tied with other layer, it's not realistic to spend more time on writing mock objects or modifying your source code to apply the mock objects. In my opinion, the recommended solution is that you should focus on Struts layer testing, if the Struts action code is close tied with other service layer which I mean is that there may be only one execute() method in every Struts action take charge for the whole business logic, you should use in-container testing, let other unit testing stuff take charge for service layer which may be out of container unit testing against EJB, in this way you can write your test case at your pleasure, forget the depended layers for a while, the container will take care for other layers for you, and also it will save you lots of time for writing mock objects, the container will give you the real objects instead of mock objects.Mock object testing is more often used for the simple Struts action or the case that it could be influenced by the container when you do unit testing against Struts action.
I will write some thing?when I have time tomorrow, sorry, it's already 1:00 AM at midnight, so you guys?could see some thing right now, hey hey. It's mainly about how to automatic do unit testing in container with strutstestcase and ANT, hope it will be useful for you guys.
由于最近在把以前的一個設(shè)計(jì)移到hibernate上來，所以需要用到one-to-one，因?yàn)樵谝郧暗脑O(shè)計(jì)中需要用到在一個主表中對于多個子表的主鍵關(guān)聯(lián)，所以一開始就想到了one-to-one的應(yīng)用，覺得這樣解決不但不會引起以前數(shù)據(jù)設(shè)計(jì)的改變，也能夠很好的利用hibernate所帶來的OR優(yōu)勢，可是當(dāng)實(shí)際使用的時候發(fā)現(xiàn)，在插入數(shù)據(jù)的時候可以有選擇的在任意子表中進(jìn)行插入，所有的結(jié)果都在原來的預(yù)期之中，但是在查詢的時候，比如說只查詢主表中的內(nèi)容
From tableMain僅僅執(zhí)行看起來十分簡單的一條語句，你所期望的是他緊緊查詢T_MAIN這張主表，可是結(jié)果確實(shí)hibernate通過多個外連接將所有的子表一口氣的全部查詢出來
select * from t_main main outer join t_sub1 sub1 on main.id = sub1.id outer join t_sub2 sub2 on main.id = sub2.id... 如此的效率絕對讓你頭痛不已，不僅如此，如果你通過首先獲得子表t_sub1的某個主鍵ID，然后通過這個主鍵查詢出子表對象，在關(guān)聯(lián)至住表，同樣的情況又會發(fā)生，又會生成類似的SQL語句，這樣一來看來對于這個設(shè)計(jì)應(yīng)用one-to-one本身就是一種錯誤，是這樣嗎？
或許有人認(rèn)為我們在每個one-to-one中加入lazy="true"這個屬性會杜絕上述情況的發(fā)生，經(jīng)過筆者的證實(shí)即便你加入了lazy="true"，也不會帶來任何的改變；又或者在hibernate.config中加入fetch depth屬性以及在每個關(guān)聯(lián)中設(shè)置outer-join="false"，這些都不會引起本質(zhì)上的變化，加入outer-join="false"其實(shí)結(jié)果只是將原有的outer join語句改變成多條sql語句而已，并沒發(fā)生什么本質(zhì)變化，反而效率更低了。
該怎么辦呢？我們先仔細(xì)研究一下one-to-one的概念，one to one代表一對一，在一般的模型中很少會遇到one-to-one這種概念，因?yàn)樗謴?qiáng)調(diào)一對一的概念，就好比一個人他只有一個身體和一個頭而已，頭和身體是十分好的例子，因?yàn)橛猩眢w必定只有一個頭，而且說到了身體必定要說頭，就好像看了某個女孩的身材必定想知道她的長相如何（-_-），所以在這時我們使用one-to-one，因?yàn)檫@種一對一的關(guān)系是很強(qiáng)的，而且從對象中取得body必定會取得他所關(guān)聯(lián)的head，這樣的情況下使用outer-join是十分方便和有效率的，因?yàn)樗褂昧薿uter join查詢從而避免了兩條到數(shù)據(jù)庫的查詢語句，而且在這種情況下也只需要在body_hbm.xml中設(shè)置一個one-to-one即可，所以在這種確實(shí)是一對一
而且在主表中一對一的關(guān)聯(lián)個數(shù)（即主表中one-to-one標(biāo)簽）十分少的情況下，使用one-to-one是一種很不錯的解決辦法。
如果一個主表會對多個子表都進(jìn)行one-to-one關(guān)聯(lián)呢，就像我們一開始遇到的這種情況，比如你不僅僅只想了解那個你中意的女孩的身材和臉蛋，而且還想知道他的學(xué)歷，身世等等一切，在這種情況下，如果我們都是用多個one-to-one在主表中的話，那情況正如我們一開始看見的，是十分可怕的，該怎么做呢？不妨考慮一下使用one-to-many，什么，many?一開始聽到many這個詞的時候，我也覺得挺驚訝的這明明是多個一對一的關(guān)聯(lián)為什么要用到many呢？其實(shí)many并沒有一定要說是大于一的，你就只在它的many中存在一個關(guān)聯(lián)它有能乃你何呢？如果用到many的話，我們就需要改動數(shù)據(jù)表的設(shè)計(jì)了，在每個有關(guān)連的子表中加入一列main_id代表主表中該記錄的主鍵子段值，只需要這樣子改動就可以了，這樣所帶來的效果絕對是值得你這樣做的，然后我們就按照以往的one-to-many來設(shè)計(jì)就好了
在body.hbm.xml加入（一到head的關(guān)聯(lián)舉例，其他的關(guān)聯(lián)按照這樣的格式添加即可）
<set name="head" inverse="true" lazy="true" cascade="all-delete-orphan">
<key column="ID0000"/>
<one-to-many class="com.xx.Head"/>
</set>
在head.hbm.xml加入
<many-to-one name="body" column="ID0000" class="com.xx.Body" not-null="true"/>
行了，經(jīng)過上面的改動我們就擺脫了查詢時多個outer-join的困擾，只在需要的時候才對子表進(jìn)行查詢，因?yàn)樵O(shè)置了lazy="true"，所以一切的一切都在我們的預(yù)料之中，我們?nèi)绻Ｍ@得body的話hibernate絕對不會把它的head 也查詢出來，節(jié)省了查詢是所需要的負(fù)擔(dān)，除非到了我們十分需要head的情況才會進(jìn)行關(guān)聯(lián)查詢，獲得所需要的head結(jié)果。
所以由此看來
在one-to-one這種一對一的關(guān)系不是很強(qiáng)的情況下，或者是在一張表中存在多個one-to-one的情況下，使用one-to-many來代替one-to-one不失為一種不錯的做法，當(dāng)然更重要的良好的數(shù)據(jù)庫設(shè)計(jì)，hibernate畢竟只是末，
千萬不要本末倒置。
one-to-one在hibernate中可以用來作為兩張表之間的主鍵關(guān)聯(lián)，這也是hibernate中主鍵關(guān)聯(lián)的一種用法，這樣在一張表中的ID，在生成另外一張表的同時回自動插入到相應(yīng)的ID字段中去，相應(yīng)的XML文件設(shè)置比較簡單，舉例如下：
<!-- 建立一對一的到Address的映射，這個是寫在User的XML配置文件中的 -->
<!-- 相應(yīng)的User bean（PO）中也要添加屬性 com.xx.Address address-->
<one-to-one name="address" cascade="all" class="com.xx.Address"/>
<!-- cascade的屬性設(shè)置不再重復(fù)了，可以查看hibernate文檔 -->
<!-- 建立一對一的到User的映射，這個是寫在Address的XML配置文件中的 -->
<!-- 相應(yīng)的Address bean（PO）中也要添加屬性 com.xx.User user--> -->
<one-to-one name="user" class="com.xx.User" constrained="true"/>
為了在Address中使用User中的主鍵ID值，我們需要設(shè)置Address中的主鍵生成規(guī)則，如下所示，采用foreign關(guān)鍵字
<id column="ID" name="id" type="long" unsaved-value="0">
<generator class="foreign">
<param name="property">user</param>
</generator>
</id>
這里需要注意的是property的屬性值必須與上面到User的映射所填寫的name屬性值一致，這樣就完成了one-to-one的映射關(guān)系。
上面的過程都很簡單，下面我來說說這里需要注意的地方：
1. 在設(shè)置屬性ID的時候必須注意字段的長度，如筆者這樣使用oracle的sequence來生成ID，其長度有14位之長，則應(yīng)選擇hibernate類型long，對應(yīng)的實(shí)體中應(yīng)選擇Long，這樣不會出現(xiàn)溢出的情況。
2. 在測試的時候必須要注意這兩張表之間因?yàn)橐呀?jīng)存在了一對一的關(guān)系，所以我們不能只寫
user.setAddress(address);
而忽略了
address.setUser(user);
這樣在做插入的時候會報出attempted to assign id from null one-to-one property: address的錯誤，這一點(diǎn)初學(xué)者會經(jīng)常犯，筆者也是其中之一。
3. 如果不寫cascade="all"或者寫成cascade="none"的話，即使你寫了
user.setAddress(address);
address.setUser(user);
也不會發(fā)生任何事情，只有user會被存儲。
以上是一些筆者經(jīng)歷的小經(jīng)驗(yàn)，如果有不對的地方歡迎指正。
在很多情況下，我們使用Hibernate在已經(jīng)建立好數(shù)據(jù)庫的基礎(chǔ)上。在oracle中，如果已經(jīng)建立好的數(shù)據(jù)庫中使用了sequence,則可以按照下面的步驟把它引入到Hibernate中：
1、在oracle 首先創(chuàng)建sequence
create sequence seq_id
minvalue 1
start with 1
increment by 1
cache 20;
2.在你的hbm.xml中的配置
<id column="ID0000" name="id" type="integer">
<generator class="sequence">
<param name="sequence">seq_id</param>
</generator>
</id>
這樣再插入數(shù)據(jù)的時候，Hibernate回自動生成如下語句：
hibernate: select seq_id.nextval from dual
hibernate: insert into YXJK.T_YXJK_WHRYTXL (XM0000, ZW0000, LXDH00, SJHM00, DZYJ00,
IP0000, ID0000) values (?, ?, ?, ?, ?, ?, ?)
自動生成下一個序列值，然后將對象插入表中。
在使用的時候需要注意，Hibernate對于sequence的主鍵的要求是一定要是shor,long，或者integer
在做具有MVC結(jié)構(gòu)的B/S程序時，怎樣將這三層隔離開是十分關(guān)鍵的，一般用DAO封裝Hibernate來獲得對數(shù)據(jù)庫的具體操作，在這里我們可以為每一個需要建立O-R MAPPING的對象（通過Hibernate實(shí)現(xiàn)OR映射）實(shí)現(xiàn)一個DAO，然后通過這個DAO來獲得具體的數(shù)據(jù)庫操作，用DAO的好處是我們可以把對一個對象的操作集中在同一個DAO中，便于管理，另外向上層只提供了接口屏蔽了底層對數(shù)據(jù)庫的操作，通過hibernate，我們向上層直接提供建立了O－R MAPPING的OBJECT；同時在領(lǐng)域模型這一層，也就是M這一層，我們將一些業(yè)務(wù)邏輯（business logic）封裝進(jìn)來，這里所指的M這一層通常也就是我們在Hibernate中所用到的plain objectS，就是用來建立O-R MAPPING所需要用到的與表對應(yīng)的OBJECTs，一般的領(lǐng)域模型都是由這些plain objectS構(gòu)成；這樣我們在控制層也就是C這一層只需要初始化DAO打開到持久層的通路，然后調(diào)用一些簡單的方法執(zhí)行業(yè)務(wù)邏輯，請注意這時候我們的業(yè)務(wù)邏輯已經(jīng)被封裝在領(lǐng)域模型這一層中了，這樣我們每一層都是相互獨(dú)立的，控制層C和展現(xiàn)層V都不和持久層所提供的接口有關(guān)系
今天的主要收獲是發(fā)現(xiàn)通過在servlet的Filter中實(shí)現(xiàn)session.begin()，session.close()，session.beginTransaction()以及transaction.commit()是一個不錯的選擇
如上圖這樣，在從服務(wù)器端返回到客戶端的時候，也就是在轉(zhuǎn)向到最終頁面的時候，由Filter實(shí)現(xiàn)關(guān)閉session和transaction，是一個很好的實(shí)現(xiàn)方法