關(guān)鍵要點(diǎn)
公司主營(yíng)業(yè)務(wù):成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化,感謝他們對(duì)我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出容城免費(fèi)做網(wǎng)站回饋大家。
可變模型應(yīng)該具備自我驗(yàn)證的能力,并實(shí)現(xiàn)驗(yàn)證接口。
在共享對(duì)象時(shí)(特別是在跨線程共享時(shí)),考慮使用不可變模型。
考慮支持MVVM風(fēng)格UI的單層和多層撤消。
在實(shí)現(xiàn)屬性變更通知時(shí)避免不必要的內(nèi)存分配。
不要覆蓋模型的Equals和GetHashCode方法。
在傳統(tǒng)的MVC、MVP、MVVM、Web MVC這些UI模式中,模型是一個(gè)公共元素。雖然有很多文章討論這些架構(gòu)中的視圖和控制器,但幾乎無一涉及模型。在本文中,我們將討論模型本身以及相應(yīng)的.NET接口。
我想先定義一些術(shù)語,這些術(shù)語在其他文章中可能有更精確的定義,但對(duì)于我們來說這些已經(jīng)足夠了。
數(shù)據(jù)模型(Data Model)
數(shù)據(jù)模型時(shí)包含數(shù)據(jù)(即屬性和集合)和行為的對(duì)象或?qū)ο髨D。數(shù)據(jù)模型是本文的重點(diǎn)。
數(shù)據(jù)傳輸對(duì)象(Data Transfer Object,DTO)
DTO是只包含屬性和集合的對(duì)象或?qū)ο髨D。一個(gè)真正的DTO沒有任何行為,而且?guī)缀跏遣豢勺兊摹?/p>
不過,在使用代碼生成工具生成DTO時(shí),通常會(huì)使用一些簡(jiǎn)單的接口(如INotifyPropertyChanged)。
對(duì)象圖(Object Graph)
一個(gè)對(duì)象圖由一個(gè)對(duì)象和所有可觸及的子對(duì)象組成。在討論數(shù)據(jù)模型和DTO時(shí),我們所說的對(duì)象圖都是單向樹狀結(jié)構(gòu)(循環(huán)圖是存在的,但它們會(huì)對(duì)序列化框架造成影響)。
領(lǐng)域模型(Domain Model)
領(lǐng)域模型是描述一組相關(guān)數(shù)據(jù)模型的更高級(jí)概念。
實(shí)體(Entity)
術(shù)語“實(shí)體”有許多定義,其中一些與“數(shù)據(jù)模型”基本相同。隨著nHibernate和Entity Framework的流行,這個(gè)術(shù)語一般是指與數(shù)據(jù)庫表一對(duì)一映射的DTO。
基于這個(gè)定義,實(shí)體可以用屬性來修飾,以便更精確地描述數(shù)據(jù)庫列和屬性之間的映射關(guān)系。它還支持從數(shù)據(jù)庫延遲加載子集合。
雖然可以通過擴(kuò)展讓實(shí)體承擔(dān)數(shù)據(jù)模型的角色,但在應(yīng)用業(yè)務(wù)邏輯之前,將實(shí)體映射到單獨(dú)的數(shù)據(jù)模型或DTO是更為常見的做法。
業(yè)務(wù)實(shí)體(Business Model)
不要與ORM的實(shí)體混淆了,這是數(shù)據(jù)模型的另一種呈現(xiàn)方式。
不可變對(duì)象(Immutable Object)
不可變對(duì)象不包含可以改變屬性的方法,它本身不是數(shù)據(jù)模型,但它可能出現(xiàn)在表示靜態(tài)查找數(shù)據(jù)的數(shù)據(jù)模型中。因?yàn)樗鼈儾荒鼙恍薷模钥缍鄠€(gè)數(shù)據(jù)模型共享一個(gè)不可變對(duì)象是安全的。
數(shù)據(jù)訪問層(Data Access Layer,DAL)
在本文中,DAL包含了服務(wù)對(duì)象、存儲(chǔ)庫、直接數(shù)據(jù)庫調(diào)用、Web服務(wù)調(diào)用等?;旧习巳魏斡糜谂c外部依賴項(xiàng)(如數(shù)據(jù)存儲(chǔ))發(fā)生交互的東西。
數(shù)據(jù)模型特征
真正的數(shù)據(jù)模型是可確定性測(cè)試(deterministically testable)的。也就是說,它們只由其他可確定性測(cè)試的數(shù)據(jù)類型組成。這意味著數(shù)據(jù)模型在運(yùn)行時(shí)不能有任何外部依賴關(guān)系。
最后一點(diǎn)很重要。如果一個(gè)類在運(yùn)行時(shí)與DAL耦合,那么它就不是數(shù)據(jù)模型。即使在編譯時(shí)使用IRepository接口來“解耦”類,也無法消除與外部依賴的關(guān)系。
在判斷什么是數(shù)據(jù)模型時(shí),要小心那些“存活實(shí)體”。為了支持延遲加載,來自O(shè)RM的實(shí)體通常會(huì)包含一個(gè)對(duì)數(shù)據(jù)庫上下文的引用。這就又讓我們回到了非確定性行為的領(lǐng)域,實(shí)體行為的變化取決于上下文狀態(tài)以及對(duì)象的創(chuàng)建方式。
換句話說,數(shù)據(jù)模型的所有方法都應(yīng)該是可預(yù)測(cè)的,而且這種預(yù)測(cè)只能基于它們的屬性值。
在父對(duì)象和子對(duì)象之間傳遞消息
父對(duì)象和子對(duì)象通常需要交互。如果做得不好,可能會(huì)導(dǎo)致難以理解的緊密交叉耦合。為了簡(jiǎn)化問題,請(qǐng)遵循以下三條規(guī)則:
基于這樣的設(shè)計(jì),可以將子對(duì)象分解出來,并在沒有父對(duì)象的情況下對(duì)其進(jìn)行測(cè)試。測(cè)試本身可以監(jiān)控只有父對(duì)象能夠處理的事件。
驗(yàn)證——數(shù)據(jù)模型唯一必須具備的功能
接下來我想談?wù)剶?shù)據(jù)模型可能會(huì)實(shí)現(xiàn)的可選特性。但在開始之前,我想先討論每個(gè)數(shù)據(jù)模型必須具備的一個(gè)特性:驗(yàn)證。
完全不處理數(shù)據(jù)的數(shù)據(jù)模型幾乎是不存在的。如果模型是來自文件、外部應(yīng)用程序或用戶界面,就有可能會(huì)引入不一致或不合法的值。來自用戶界面的問題會(huì)更多,因?yàn)橛脩敉ǔP枰饌€(gè)字段得填寫表單。
因?yàn)榇嬖谶@些限制,所以不能在構(gòu)造函數(shù)和屬性設(shè)置器中使用異常,就像你在其他類中使用異常一樣。不過可以驗(yàn)證接口,為錯(cuò)誤檢查提供一些靈活性。
.NET提供了一些開箱即用的驗(yàn)證接口,不過每個(gè)人都有自己特定的需求。
IDataErrorInfo
IDataErrorInfo接口早就可以用了,不過現(xiàn)在基本被棄用,因?yàn)樗闷饋砗苈闊?。讓我們來看看它的屬性?/p>
string Error {get;}:這個(gè)屬性有三個(gè)用途:
string this[string columnName] {get;}:這個(gè)索引器屬性將返回屬性特定的錯(cuò)誤。
正如你所看到的,Error屬性做的事情太多了,它將所有東西都拼湊成一個(gè)字符串,從而無法區(qū)分對(duì)象級(jí)別和屬性級(jí)別的驗(yàn)證錯(cuò)誤。如果你重新定義它,讓它只包含對(duì)象級(jí)錯(cuò)誤,那么就無法知道對(duì)象作為整體是否包含錯(cuò)誤。
至于索引器,你會(huì)怎么調(diào)用它?要訪問它的唯一方法是將該對(duì)象轉(zhuǎn)換成IDataErrorInfovariable。然后,很少有人會(huì)期望看到這樣的代碼:
var nameError = ((IDataErrorInfo)customer)["Name"];
如果你的UI框架需要這個(gè)接口,我建議你將它放到一個(gè)基類中,并提供更合理的驗(yàn)證API。一旦加入真實(shí)的驗(yàn)證邏輯,甚至可以忽略IDataErrorInfo的存在。
INotifyDataErrorInfo的常規(guī)定義
我將分兩次討論INotifyDataErrorInfo接口。在本小節(jié)中,我將解釋本該如何使用INotifyDataErrorInfo,然后在下一個(gè)小節(jié)解釋我認(rèn)為應(yīng)該如何使用它。
INotifyDataErrorInfo接口旨在支持Silverlight 4中的異步驗(yàn)證,其基本想法是修改屬性會(huì)觸發(fā)服務(wù)調(diào)用,被調(diào)用的服務(wù)最終會(huì)結(jié)束并更新錯(cuò)誤狀態(tài)。
這個(gè)接口的唯一屬性是bool HasErrors {get;},不過關(guān)于如何實(shí)現(xiàn)這個(gè)屬性并沒有硬性規(guī)定。我們有兩個(gè)基本選項(xiàng),但都不可行。
如果只是進(jìn)行一般的顯示,只要在發(fā)生EventHandler
此外,ErrorsChanged理論上可以觸發(fā)兩次:一次是立即觸發(fā),另一次是異步驗(yàn)證完成后觸發(fā)。這可能會(huì)產(chǎn)生奇怪的UI效果,因?yàn)镠asErrors會(huì)在兩種狀態(tài)之間切換。
最后是IEnumerable GetErrors(string propertyName)方法,這個(gè)方法用于驗(yàn)證屬性。不過,你也可以傳給它一個(gè)null或空字符串來獲取對(duì)象級(jí)驗(yàn)證錯(cuò)誤。
它返回的是IEnumerable而不是IEnumerable
不過缺乏類型安全并不是唯一的問題,這段話摘自它的文檔:
此方法返回一個(gè)IEnumerable,在異步驗(yàn)證完成處理之前,可能會(huì)發(fā)生變化。綁定引擎因此能夠在添加、刪除或修改錯(cuò)誤時(shí)自動(dòng)更新用戶界面驗(yàn)證反饋。
如果這個(gè)方法返回一個(gè)IObservable,或許就沒有問題。但是在這種情況下,IEnumerable能夠奏效的唯一方法是讓它在等待異步驗(yàn)證完成之前阻塞。這樣仍然會(huì)導(dǎo)致UI掛起。
然后是封裝問題。如前所述,數(shù)據(jù)模型應(yīng)該完全沒有任何外部依賴。屬性變化不應(yīng)直接調(diào)用服務(wù),因?yàn)檫@會(huì)使該類變得非常難以測(cè)試。如果你需要異步驗(yàn)證某些內(nèi)容,請(qǐng)?jiān)诳刂破骰蛞晥D模型中執(zhí)行此操作。
INotifyDataErrorInfo的正確用法
盡管存在缺陷,但I(xiàn)NotifyDataErrorInfo已經(jīng)被用在很多UI框架中,所以我們無法忽略它。所幸的是,我們可以在不破壞兼容性的情況下重新定義它。
HasErrors屬性可以在其他屬性發(fā)生變化時(shí)進(jìn)行同步更新。如果一個(gè)類實(shí)現(xiàn)了INotifyPropertyChanged,并且值發(fā)生變化,就會(huì)觸發(fā)PropertyChanged事件。
不管指定的屬性是有效還是無效,都應(yīng)該觸發(fā)ErrorsChanged事件。如果對(duì)象級(jí)驗(yàn)證已經(jīng)發(fā)生變化,則應(yīng)使用null或字符串觸發(fā)ErrorsChanged事件。
在新模型中,GetErrors應(yīng)該始終返回一個(gè)支持IEnumerable
基于屬性的驗(yàn)證
我們可以使用基于屬性的驗(yàn)證完成很多工作,雖然這樣并不適合所有的情況。方法是在屬性上放置ValidationAttribute的子類。這里有些例子:
要?jiǎng)?chuàng)建自己的驗(yàn)證屬性類,只需重寫IsValid方法。通常這用于單屬性驗(yàn)證,不過也可以通過ValidationContext來訪問對(duì)象的其他屬性。
基于屬性的驗(yàn)證的一個(gè)優(yōu)點(diǎn)是,一些框架(比如ASP.NET MVC/WebAPI)已經(jīng)選定它作為驗(yàn)證接口。因?yàn)樗锹暶魇降?,所以可以與UI共享驗(yàn)證邏輯。
混合命令式和基于屬性的驗(yàn)證
雖然理論上可以使用驗(yàn)證屬性來完成所有工作,但有時(shí)候使用普通代碼可以更容易地實(shí)現(xiàn)嚴(yán)格的驗(yàn)證。這樣做的原因如下:
命令式驗(yàn)證的一個(gè)缺點(diǎn)是它只存在于服務(wù)器端,無法像使用基于屬性的驗(yàn)證一樣自動(dòng)與UI共享驗(yàn)證邏輯。
命令式驗(yàn)證的另一個(gè)限制是它需要使用共享接口,這樣才能讓應(yīng)用程序的其余部分通過一致的方式觸發(fā)驗(yàn)證。
空表單問題
當(dāng)用戶在創(chuàng)建新記錄并未填寫所有必填字段時(shí),就會(huì)出現(xiàn)空表單問題。在顯示表單時(shí),你不希望看到每個(gè)字段都以紅色突出顯示。
為了解決這個(gè)問題,需要為模型提供兩個(gè)額外的方法:
對(duì)于這種模型,模型對(duì)象將從初始狀態(tài)開始。如果它在顯示給用戶之前已經(jīng)包含了部分值,則應(yīng)該在向用戶顯示之前調(diào)用清除錯(cuò)誤的方法。
當(dāng)用戶修改某個(gè)字段時(shí),只驗(yàn)證該字段。然后,在保存之前,可以調(diào)用驗(yàn)證方法強(qiáng)制對(duì)模型進(jìn)行全面檢查,包括非用戶修改的屬性。
理論上的驗(yàn)證接口
我認(rèn)為.NET的驗(yàn)證接口應(yīng)該看起來像這樣:
public interface IValidatable { /// This forces the object to be completely revalidated. bool Validate(); /// Clears the error collections and the HasErrors property void ClearErrors(); /// Returns True if there are any errors. bool HasErrors { get; } /// Returns a collection of object-level errors. ReadOnlyCollectionGetErrors(); /// Returns a collection of property-level errors. ReadOnlyCollection GetErrors(string propertyName); /// Returns a collection of all errors (object and property level). ReadOnlyCollection GetAllErrors(); /// Raised when the errors collection has changed. event EventHandler ErrorsChanged; }
你可以在Tortuga Anchor庫中看到這個(gè)接口的實(shí)現(xiàn)。
IValidatableObject
如果不簡(jiǎn)要討論下IValidatableObject接口,那就是我的失職。這個(gè)接口只有一個(gè)方法IEnumerable
我很喜歡這個(gè)方法,因?yàn)樗梢杂|發(fā)對(duì)象的完整驗(yàn)證,所以它可以解決空表單問題。它返回ValidationResult對(duì)象,比原始字符串要好得多。
缺點(diǎn)是它接受ValidationContext對(duì)象作為參數(shù),而幾乎沒有人知道如何使用這個(gè)類。以下是ValidationContext的屬性。
關(guān)于如何使用這些屬性并沒有相關(guān)的指南。例如,什么時(shí)候應(yīng)該設(shè)置MemberName屬性? DisplayName屬性實(shí)際上做了什么?字典中應(yīng)該保存什么以及在驗(yàn)證期間何時(shí)可以訪問它?
文檔中說它“可以通過任何實(shí)現(xiàn)IServiceProvider接口的服務(wù)添加自定義驗(yàn)證”,但并沒有說明IServiceProvider.GetService(Type)方法需要支持哪些類型,因此無法利用此特性。
總而言之,ValidationContext類想要做所有的事情,但由于糟糕的API設(shè)計(jì)和幾乎沒有詳盡的文檔,它變得一無是處。由于沒有UI框架使用這個(gè)接口,所以沒有理由支持它或IValidatableObject接口。
屬性變更通知
屬性變更通知在很多情況下都很有用,不過更常見的是與MVVM設(shè)計(jì)模式相關(guān)聯(lián)。屬性變更通知通過INotifyPropertyChanged接口公開出來,讓模型可以通知關(guān)聯(lián)的UI元素:基礎(chǔ)數(shù)據(jù)發(fā)生了變化。我們可以借此做一些有趣的事情,比如在后臺(tái)進(jìn)程中更新模型或者在多個(gè)視圖之間共享模型。
實(shí)現(xiàn)屬性變更通知最簡(jiǎn)單的辦法是每次在調(diào)用屬性設(shè)置器時(shí)觸發(fā)它們。雖然從技術(shù)方面看是可行的,但仍有一些性能方面的影響。
public string Name { get { return m_Name; } set { m_Name = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name))); } }
在上面的示例中,即使沒有不存在任何偵聽者,每個(gè)屬性變更通知讓然會(huì)分配一個(gè)新對(duì)象來保存屬性名稱。如果這些通知頻繁發(fā)生,則可能會(huì)觸發(fā)不必要的垃圾回收。為了避免這種情況,應(yīng)該把PropertyChangedEventArgs對(duì)象緩存起來。
另一個(gè)問題是事件可能是不必要的。如果屬性值實(shí)際上沒有發(fā)生改變,就相當(dāng)于無緣無故地觸發(fā)屏幕重繪。所以我們需要做一個(gè)簡(jiǎn)單的檢查:
static readonly PropertyChangedEventArgs NameProperty = new PropertyChangedEventArgs(nameof(Name)); public string Name { get { return m_Name; } set { if (m_Name == value) return; m_Name = value; PropertyChanged?.Invoke(this, NameProperty); } }
這個(gè)過程可能非常繁瑣,因此就有了“MVVM框架”,用來減少這些噪音。Get和Set方法與內(nèi)部字典一起使用,用來維護(hù)狀態(tài)。通過這種方式,可以為我們處理PropertyChangedEventArgs緩存和屬性值變更改檢查。具體細(xì)節(jié)會(huì)有所不同,但它們或多或少看起來像這個(gè)來自Tortuga Anchor的例子。
public string Name { get => Get(); set => Set(value); }
請(qǐng)注意,這種便利性可能會(huì)對(duì)性能造成一點(diǎn)影響。訪問內(nèi)部字典比使用字段慢,并且值的裝箱操作可能會(huì)消除緩存PropertyChangedEventArgs所帶來的收益。
如果你只編寫服務(wù)器端代碼,可能會(huì)想“我沒有UI,所以我不需要這些”。如果真是這樣,或許你是對(duì)的。但有時(shí)候使用INotifyPropertyChanged可以簡(jiǎn)化一些復(fù)雜的代碼。我建議服務(wù)器端開發(fā)人員至少將其視為一種選擇。
INotifyPropertyChanging
這個(gè)是INotifyPropertyChanged的孿生兄弟,會(huì)在屬性值發(fā)生變更之前觸發(fā)。其目的是讓消費(fèi)者緩存先前的值。LINQ和Entity Framework等ORM框架可能會(huì)利用這些信息進(jìn)行跟蹤。
ISupportInitialize/ISupportInitializeNotification
ISupportInitialize的目的是臨時(shí)禁用屬性/集合變更通知、錯(cuò)誤驗(yàn)證等。要使用它,請(qǐng)?jiān)谶M(jìn)行屬性變更之前先調(diào)用BeginInit。
當(dāng)調(diào)用EndInit時(shí),可以發(fā)送一個(gè)“everything changed”變更通知。這個(gè)是通過使用一個(gè)包含null或空屬性名稱的PropertyChangedEventArgs對(duì)象來完成的。
如果希望在初始化完成時(shí)收到通知,可以給ISupportInitializeNotification接口添加Initialized事件和IsInitialized屬性。
集合變更通知
正如我們需要知道單個(gè)屬性的變更一樣,我們也需要知道整個(gè)集合發(fā)生的變更。我們可以使用INotifyCollectionChanged接口來解決這個(gè)問題。
可惜的是,INotifyCollectionChanged遠(yuǎn)不如它的名字所暗示的那么強(qiáng)大。從理論上講,CollectionChanged相關(guān)事件可以使用單個(gè)事件來告訴我們何時(shí)已將整組對(duì)象添加到集合中或從集合中刪除。但實(shí)際上,因?yàn)閃PF中存在的設(shè)計(jì)缺陷導(dǎo)致無法實(shí)現(xiàn)這樣的功能。
INotifyCollectionChanged最著名的實(shí)現(xiàn)是ObservableCollection
由于這個(gè)錯(cuò)誤,沒有人可以實(shí)現(xiàn)帶有批量更新支持的INotifyCollectionChanged,除非他們100%確定集合類不會(huì)被用在WPF中。
因此,我的建議是不要試圖從頭開始創(chuàng)建自定義集合類。只需使用ObservableCollection
類型安全的集合變更事件
除了沒有人使用的功能之外,INotifyCollectionChanged接口的另一個(gè)問題是,它不是類型安全的。如果類型對(duì)你來說非常重要,則必須執(zhí)行(理論上)不安全的轉(zhuǎn)換或編寫代碼來處理永遠(yuǎn)不會(huì)發(fā)生的情況。為了解決這個(gè)問題,我建議實(shí)現(xiàn)這個(gè)接口:
////// This is a type-safe version of INotifyCollectionChanged /// ///public interface INotifyCollectionChanged { /// /// This type safe event fires after an item is added to the collection no matter how it is added. /// ///Triggered by InsertItem and SetItem event EventHandler> ItemAdded; /// /// This type safe event fires after an item is removed from the collection no matter how it is removed. /// ///Triggered by SetItem, RemoveItem, and ClearItems event EventHandler> ItemRemoved; }
這不僅解決了類型安全問題,而且不需要檢查NotifyCollectionChangedEventArgs.NewItems的大小。
集合中的屬性變更通知
.NET中另一個(gè)“缺失的接口”是能夠檢測(cè)集合中某個(gè)項(xiàng)目屬性何時(shí)發(fā)生變化。比方說,你有一個(gè)OrderCollection類,并且需要在屏幕上顯示TotalPrice屬性。為了保持這個(gè)屬性的準(zhǔn)確性,你需要知道每個(gè)項(xiàng)目的單價(jià)何時(shí)發(fā)生變化。
對(duì)于我自己的集合,我經(jīng)常會(huì)公開一個(gè)INotifyItemPropertyChanged接口,用于將集合中對(duì)象的任意PropertyChanged事件轉(zhuǎn)成單個(gè)ItemPropertyChanged事件。
為此,集合需要在將對(duì)象添加到集合或從集合中移除時(shí)附加和移除事件處理程序。
變更跟蹤和撤消
雖然使用不是很頻繁,.NET還是提供了專門用于跟蹤對(duì)象變更的接口,這些接口甚至還提供了撤消功能。
變更跟蹤
從表面上看,IChangeTracking接口看起來好像很容易理解:對(duì)象發(fā)生變化或者沒有發(fā)生變化。但實(shí)際上它有點(diǎn)微妙。
從用戶界面角度來看,用戶通常想知道的是“這個(gè)對(duì)象或它的任何子對(duì)象是否發(fā)生變化了?”
從數(shù)據(jù)存儲(chǔ)角度來看,你希望知道對(duì)象本身是否發(fā)生了變化。
文檔里沒有提到這些,因?yàn)樗鼪]有定義一個(gè)子對(duì)象是否被認(rèn)為是“對(duì)象內(nèi)容”的一部分。我個(gè)人偏好讓IsChanged包含子對(duì)象的變化,并為數(shù)據(jù)存儲(chǔ)添加單獨(dú)的IsChangedLocal屬性。
可恢復(fù)變更跟蹤
IRevertableChangeTracking添加了一個(gè)RejectChanges方法來撤消任何掛起的更改。這里存在同樣的問題,即這個(gè)方法適用于本地對(duì)象還是子對(duì)象。
我通常假設(shè)RejectChanges會(huì)遍歷對(duì)象圖,并拒絕所有掛起的變更。但在涉及集合屬性時(shí),這可能有點(diǎn)蹊蹺,最好是將其封裝在類中,而不是嘗試構(gòu)建臨時(shí)解決方案。
可編輯的對(duì)象
與IChangeTracking不同,IEditableObject專門用于UI場(chǎng)景中。具體地說,就是用在提供確定/取消語義的對(duì)話框和數(shù)據(jù)網(wǎng)格中。
在顯示對(duì)話框或?qū)?shù)據(jù)網(wǎng)格切換到編輯模式之前,必須調(diào)用BeginEdit來捕捉對(duì)象的快照。EndEdit清除快照,而CancelEdit將對(duì)象恢復(fù)到之前的狀態(tài)。請(qǐng)注意,大多數(shù)數(shù)據(jù)網(wǎng)格會(huì)自動(dòng)為你調(diào)用這些方法。
如果你同時(shí)使用了IEditableObject和IRevertableChangeTracking,那么我建議將其實(shí)現(xiàn)為兩級(jí)撤消,并讓IEditableObject處于第二級(jí)。或者換句話說,在調(diào)用RejectChange時(shí)同時(shí)調(diào)用CancelEdit,但不能反過來。
遺失的屬性變更接口
在ORM集成中極有可能缺失一些接口。我們可以使用IChangeTracking來告訴ORM是否需要保存給定的記錄,但并沒有接口告訴我們哪些屬性已經(jīng)發(fā)生改變。這意味著ORM需要單獨(dú)跟蹤發(fā)生變更的字段,或者假設(shè)所有內(nèi)容都發(fā)生變化,并將整個(gè)對(duì)象重新保存到數(shù)據(jù)庫。
Equals、GetHashCode和IEquatable
這是我建議避免的一系列特性。根據(jù)我們的定義,數(shù)據(jù)模型是可變的。如果它們是不可變的,那么上述的接口都沒有任何意義。
問題是你不能使用可變屬性來安全地實(shí)現(xiàn)GetHashCode和Equals。字典會(huì)假設(shè)散列碼永遠(yuǎn)不會(huì)改變,所以如果一個(gè)對(duì)象被當(dāng)作字典的鍵,就會(huì)破壞字典的功能。
此外,對(duì)于數(shù)據(jù)模型來說,Equality究竟意味著什么?它們代表數(shù)據(jù)庫表中的同一行(即主鍵)?或者兩個(gè)對(duì)象的每個(gè)屬性都相同?不管你如何回答這個(gè)問題,你的團(tuán)隊(duì)中的其他人必定會(huì)有不同的答案。
如果你覺得必須要有非默認(rèn)的Equals或GetHashCode實(shí)現(xiàn),請(qǐng)考慮創(chuàng)建一個(gè)IEqualityComparer
同樣,你可能希望為排序提供一個(gè)或多個(gè)Comparer
ICloneable
眾所周知,我們不應(yīng)該實(shí)現(xiàn)ICloneable接口,因?yàn)槲覀儚膩矶疾恢酪粋€(gè)對(duì)象克隆是深拷貝還是淺拷貝。
當(dāng)然,這并不意味著你絕對(duì)不應(yīng)該提供克隆方法。如果你選擇提供克隆方法,就應(yīng)該非常清楚地了解被克隆的內(nèi)容?;蛘呖梢詫⑵浞Q為ShallowClone或DeepClone。
總結(jié)性思考
模型是構(gòu)建和理解應(yīng)用程序的基礎(chǔ)。你花在彌補(bǔ)缺口上的時(shí)間,比如不一致的命名約定、缺少的特性和不正確實(shí)現(xiàn)的接口,最終都會(huì)獲得回報(bào)。
關(guān)于作者
Jonathan Allen 在90年代后期開始為一家健康診所開發(fā)MIS項(xiàng)目,將逐步從Access和Excel遷移成為一個(gè)企業(yè)解決方案。在為金融行業(yè)開發(fā)自動(dòng)交易系統(tǒng)五年后,他成為各種項(xiàng)目的顧問,其中包括機(jī)器人倉庫的用戶界面、癌癥研究軟件的中間層以及大型房地產(chǎn)保險(xiǎn)公司的大數(shù)據(jù)解決方案。在空閑時(shí)間,他喜歡學(xué)習(xí)有關(guān)16世紀(jì)武術(shù)的東西。
查看英文原文:Models and Their Interfaces in C# API Design
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,如果有疑問大家可以留言交流,謝謝大家對(duì)創(chuàng)新互聯(lián)的支持。