01

—

約定

在收到Caliburn Micro中有關視圖和ViewModel解析的反饋后，我們添加了新功能，以簡化類型解析，同時保持驅動它的健壯的基于正則表達式的名稱轉換機制。為了更好地了解這些新功能以及類型解析通常如何在框架中工作，現在是詳細描述框架支持的開箱即用的命名約定的適當時機。您現在應該已經知道，框架很大程度上依賴于命名約定，在類型解析中，需要考慮兩種不同的命名約定：命名類型本身的約定和命名類型命名空間的約定。

類型名稱的命名約定

如本文檔其他部分所述，視圖及其伴生ViewModel最常見的命名約定如下所示：

因為我們認識到“視圖”是一個抽象的術語，大多數應用程序的主要“視圖”實際上是某種“頁面”，所以我們認為框架將“頁面”作為“視圖”的同義詞是很重要的。因此，該框架對該用例具有內置支持：

如果仔細檢查，您會發(fā)現上面兩個約定之間存在細微的差異。“ViewModel”只是簡單地添加到一個帶有后綴名的“頁面”中，以生成其ViewModel的名稱。但是，只有“模型”添加到“視圖”后綴名中，以生成其伴生ViewModel的名稱。這種差異主要源于將某些東西命名為“MainViewModel”而不是“MainPageViewModel”的語義尷尬。因此，從“視圖”后綴視圖名稱派生的視圖模型的命名約定通過將視圖模型命名為“MainViewModel”來避免冗余。

框架支持的標準命名約定的一個限制是，沒有考慮到英語中的不同語言甚至不同術語。盡管“視圖”和“視圖模型”可以被普遍理解，因為它們都是Caliburn Micro致力于的MVVM設計模式的重要方面，但“頁面”這樣的詞卻不是。因此，一個健壯的框架至少允許通過定制來支持額外的“視圖名稱后綴”（例如“Pagina”、“Seite”、“Form”、“Screen”）。

多視圖支持的命名約定

如文檔約定部分所述，該框架旨在處理ViewModel和View之間的一對多關系。框架支持的標準公約如下：

如前一節(jié)所述，ViewModel的名稱可能包含也可能不包含“視圖”后綴。這就是為什么顯示為可選的原因。

類型的命名空間的命名約定

在.NET開發(fā)中，所有程序集都必須有一個默認命名空間。因此，最基本的用例中，視圖和視圖模型組件層都位于同一個用例中。這項公約可描述如下：

雖然許多應用程序的所有視圖和視圖模型都可能位于單個部件中，但通常的做法是在項目中的單獨文件夾中組織視圖和視圖模型。因此，默認情況下，VisualStudio將把組件放在與這些文件夾相對應的單獨名稱空間中。由于項目文件夾類似于操作系統文件夾，因此項目子文件夾也可以嵌套在多層中。此常見用例的命名空間命名約定可以描述如下：

盡管上面的約定涵蓋了嵌套名稱空間的深度方面的許多可能性，但它確實在視圖和視圖模型的組織方案中假設了一種并行結構。此外，將視圖和視圖模型放置到單獨的部件中也是很常見的，這使得跨不同部件進行并行組織的可能性更小。

02

—

最后

原文標題：Caliburn.Micro Xaml made easy

原文鏈接：https://caliburnmicro.com/documentation/naming-conventions

翻譯：dotnet編程大全

C#技術群?:?添加小編微信mm1552923，備注：進群！

總結

以上是生活随笔為你收集整理的C# WPF MVVM开发框架Caliburn.Micro View / View Model 命名⑨的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。