|
|
正式討論之前，先看看這兩個問題：當(dāng)我們的對象所涉及的操作不斷增加時，我們是否應(yīng)該：Book.Save，Book.Serialize，Book.Method1，Book.Method2這樣一直增加下去？或者在某個垂直的邏輯中增加其它邏輯時，不斷的擴(kuò)充Book.Save，要么象有的朋友說的那樣分離出去，再回調(diào)？但是Book.Save有理又有在，無論數(shù)據(jù)->對象，還是對象->數(shù)據(jù)，考慮到數(shù)據(jù)和對象經(jīng)常一起變化，恢復(fù)對象的狀態(tài)這部分確實(shí)應(yīng)該留在對象內(nèi)部，同時，我也認(rèn)可這本來就是對象的職責(zé)。
為了大家所謂的“低耦高聚”的目標(biāo)，也為了保持職責(zé)的合理性，希望大家考慮一下，當(dāng)Book沒有Save時，我們除了屬性賦值是不是就無路可走了？這就得那些沒包含在這次討論中的習(xí)慣性做法(比如平時對.NETFramework和ADO.NET的使用方式)包含近來，看看很多同志指出的美女走光問題，除了給美女一個電棍讓美女負(fù)擔(dān)起警察打擊偷窺者的職責(zé)，能不能通過換件裙子來解決。
我們平時用慣了IDataReader給對象賦值，所以很多人說的那種，從外部通過屬性賦值的情況就廣泛存在，比如CommunityServer。如果換一個方式呢? 把IDataReader直接交給Book，然后Book自己展開數(shù)據(jù)是不是好很多呢？于是有人又說了，這跟IDataReader耦合了，不利于移植等等。或者我根本沒用ADO，所以沒IDataReader。后者可以通過給自己的數(shù)據(jù)操作層實(shí)現(xiàn)IDataReader搞定；關(guān)鍵是前者，前者的非法性還表現(xiàn)在，把ADO的接口帶入了邏輯層；等等等等, 反正很多。那么為什么不能自己做一些類似IDataReader的接口，然后把ADO.NET包含的概念作為變化封裝出去呢?
在保存數(shù)據(jù)的時候也一樣，不是把數(shù)據(jù)全部讀出來去保存，而是讓Book準(zhǔn)備好需要保存的數(shù)據(jù)，總而言之歸它管的一分不落，然后實(shí)現(xiàn)或者返回出一個統(tǒng)一的接口里面全都是要持久的數(shù)據(jù)。至于如何跑回書架上，或者被賊給偷跑了，那是別人的事。畢竟某兄弟回復(fù)說的，今天加個Cache明天加個Log后天加個Permission最后數(shù)據(jù)庫都不用了的情況也確實(shí)有。這些都該Book負(fù)責(zé)嗎?不是說只添加不修改嗎?難道非得要求必須AOP? 我是Anders的忠實(shí)Fans，我不認(rèn)為AOP解決了什么本質(zhì)問題。怎么又說回職責(zé)問題了，總而言之，現(xiàn)在總不能有人說美女走光了吧。
其實(shí)我們所說的方法，往往都有學(xué)習(xí)的對象，大家可以想想各種Control對于ViewState的使用,它其實(shí)就是這么一個玩意(關(guān)于Control如何使用和持久化ViewState的文章，園子里就有)。那么我們也可以這樣，數(shù)據(jù)就是數(shù)據(jù)，要什么屬性，而且IDataReader出來的不就是一砣類似字典的東西嗎？正好直接拿字符串和我們自己定義BL層與數(shù)據(jù)層之間對接的接口對應(yīng)(與IDataReader不同的是，我們定義的接口是在邏輯層中使用的，除了象一個數(shù)據(jù)集，不包含任何和數(shù)據(jù)層相關(guān)的內(nèi)容)，覺得不過癮，把對應(yīng)關(guān)系保存到配置文件里去。無論如何，希望讓對象自己負(fù)責(zé)恢復(fù)狀態(tài)，同時又不希望對象負(fù)責(zé)存取邏輯的矛盾，并非無法解決，ViewState的方式只是其中一種解決方法。
我們不妨再看看.NETFramework如何讓Serializer和你的對象在沒有聯(lián)系的情況下，通過增加一個翟通道，即不介入對象內(nèi)部邏輯，又負(fù)擔(dān)了對象持久的：首先實(shí)現(xiàn)ISerializer這一接口，同時實(shí)現(xiàn)固定方法簽名的構(gòu)造函數(shù)。保存數(shù)據(jù)時，他讓你自己打包然后從你的接口實(shí)現(xiàn)中獲得數(shù)據(jù)對象，恢復(fù)對象時，他調(diào)用你那個特別的構(gòu)造函數(shù)，把數(shù)據(jù)字典還給你，然后讓你自己填充。拿Book來說，如果增加了需求，難道非得讓Book自己重新實(shí)現(xiàn)一個Book.Serialize方法嗎？鑒于一些朋友可能不清楚Serializer的工作機(jī)制，我借用一下MSDN的簡單例子，同時有所改動：
[Serializable]
public class MyObject : ISerializable
{
public int N1 { get; private set;} //公開取，私有存
public int N2 { get; internal set;} //公開讀，內(nèi)部存
public String Str { get; set;} //這些是VS 2008支持的寫法，不用自己定義私有變量了
public MyObject()
{
}
protected MyObject(SerializationInfo info, StreamingContext context)
{
//這個特殊的構(gòu)造函數(shù)會被自動調(diào)用，如果是我們自己實(shí)現(xiàn)，就某Manager調(diào)用
//其實(shí)如果沒有復(fù)雜的構(gòu)造函數(shù)初始化邏輯，比如給readonly變量賦值
//可以將SetObjectData直接實(shí)現(xiàn)于接口，由我們負(fù)責(zé)數(shù)據(jù)存取的部分來調(diào)用
SetObjectData(info);
}
protected virtual void SetObjectData(SerializationInfo info)
{
N1= info.GetInt32("i"); //由對象自己將數(shù)據(jù)字典展開
N2 = info.GetInt32("j"); //還原對象狀態(tài)
Str = info.GetString("k"); //這樣就可以把跟對象無關(guān)的存儲邏輯外包出去
}
[SecurityPermissionAttribute(SecurityAction.Demand,SerializationFormatter=true)]
public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
{
info.AddValue("i", N1);//info可以理解為Serializer定義的數(shù)據(jù)字典格式
info.AddValue("j", N2);//這相當(dāng)于持久化的概念進(jìn)入了BL層
info.AddValue("k", Str);//所以當(dāng)我們實(shí)現(xiàn)時，應(yīng)該根據(jù)業(yè)務(wù)邏輯定義自己的數(shù)據(jù)字典
}
}
Serializer：
BinaryFormatter formatter = new BinaryFormatter();
保存至fs：
formatter.Serialize(fs, a1);
從fs讀取：
formatter.Deserialize(fs);
it知識庫：怪怪設(shè)計(jì)論閑談篇：職責(zé)與解耦的矛盾，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
