真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

C#API中模型與它們的接口設(shè)計(jì)詳解

關(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ī)則:

  1. 父對(duì)象可以直接與子對(duì)象的屬性和方法交互。
  2. 子對(duì)象只能通過觸發(fā)事件與父對(duì)象進(jìn)行交互。
  3. 對(duì)象不能直接與兄弟對(duì)象交互,兄弟對(duì)象之間的消息必須通過共同的父對(duì)象來傳遞。

基于這樣的設(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è)用途:

  • 報(bào)告對(duì)象級(jí)別的錯(cuò)誤
  • 報(bào)告所有屬性級(jí)別的錯(cuò)誤
  • 通過返回一個(gè)空字符串來表示不存在錯(cuò)誤

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),但都不可行。

  1. 阻塞直到異步驗(yàn)證完成,這樣會(huì)掛起UI。
  2. 立即返回,這會(huì)讓調(diào)用變得不確定,因?yàn)槟悴恢朗欠翊嬖趻炱鸬漠惒津?yàn)證請(qǐng)求。

如果只是進(jìn)行一般的顯示,只要在發(fā)生EventHandler ErrorsChanged事件時(shí)更新HasErrors屬性即可。不過,如果你嘗試單擊“保存”按鈕同步檢查驗(yàn)證狀態(tài),那這就不是一個(gè)好辦法。

此外,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è)C# 1的接口,而不是泛型。

不過缺乏類型安全并不是唯一的問題,這段話摘自它的文檔:

此方法返回一個(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的集合類。ValidationResult類提供了有用的信息,例如哪些屬性是驗(yàn)證警告的一部分。這對(duì)于一些錯(cuò)誤消息來說非常管用,比如“至少需要提供名字/姓氏中的一個(gè)”。

基于屬性的驗(yàn)證

我們可以使用基于屬性的驗(yàn)證完成很多工作,雖然這樣并不適合所有的情況。方法是在屬性上放置ValidationAttribute的子類。這里有些例子:

  • CreditCardAttribute
  • EmailAddressAttribute
  • EnumDataTypeAttribute
  • FileExtensionsAttribute
  • PhoneAttribute
  • UrlAttribute
  • MaxLengthAttribute
  • MinLengthAttribute
  • RangeAttribute
  • RegularExpressionAttribute
  • RequiredAttribute
  • StringLengthAttribute

要?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)證規(guī)則涉及多個(gè)屬性
  • 驗(yàn)證規(guī)則涉及子對(duì)象
  • 驗(yàn)證規(guī)則不會(huì)被其他類或?qū)傩灾赜?/li>

命令式驗(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è)額外的方法:

  • 驗(yàn)證:跨所有字段執(zhí)行驗(yàn)證,觸發(fā)類似“required”這樣的規(guī)則。
  • 清除錯(cuò)誤:從對(duì)象中刪除所有已觸發(fā)的驗(yàn)證錯(cuò)誤。

對(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.
 ReadOnlyCollection GetErrors();

 /// 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 Validate(ValidationContext validationContext)。

我很喜歡這個(gè)方法,因?yàn)樗梢杂|發(fā)對(duì)象的完整驗(yàn)證,所以它可以解決空表單問題。它返回ValidationResult對(duì)象,比原始字符串要好得多。

缺點(diǎn)是它接受ValidationContext對(duì)象作為參數(shù),而幾乎沒有人知道如何使用這個(gè)類。以下是ValidationContext的屬性。

  • DisplayName:獲取或設(shè)置要驗(yàn)證成員的名稱。
  • Items:獲取與此上下文關(guān)聯(lián)的鍵值對(duì)字典。
  • MemberName:獲取或設(shè)置要驗(yàn)證成員的名稱。
  • ObjectInstance:獲取要驗(yàn)證的對(duì)象。
  • ObjectType:獲取要驗(yàn)證的對(duì)象類型。
  • ServiceContainer:獲取驗(yàn)證服務(wù)容器。

關(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è)類旨在為每個(gè)添加或刪除的項(xiàng)目觸發(fā)一個(gè)單獨(dú)的CollectionChanged事件。在設(shè)計(jì)WPF時(shí),它假設(shè)我們總是會(huì)使用ObservableCollection,因此WPF不支持NotifyCollectionChangedEventArgs.NewItems具有多個(gè)項(xiàng)目的情況。

由于這個(gè)錯(cuò)誤,沒有人可以實(shí)現(xiàn)帶有批量更新支持的INotifyCollectionChanged,除非他們100%確定集合類不會(huì)被用在WPF中。

因此,我的建議是不要試圖從頭開始創(chuàng)建自定義集合類。只需使用ObservableCollection或ReadOnlyObservableCollection作為基類,然后在其上添加所需的任何附加特性。

類型安全的集合變更事件

除了沒有人使用的功能之外,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。它不屬于數(shù)據(jù)模型,所以其他人可以理解你的做法是非標(biāo)準(zhǔn)的行為。

同樣,你可能希望為排序提供一個(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)的支持。


當(dāng)前題目:C#API中模型與它們的接口設(shè)計(jì)詳解
文章轉(zhuǎn)載:http://weahome.cn/article/gshijp.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部