当前位置: 代码迷 >> 综合 >> C# WPF MVVM开发框架Caliburn.Micro View / View Model 命名⑨
  详细解决方案

C# WPF MVVM开发框架Caliburn.Micro View / View Model 命名⑨

热度:11   发布时间:2024-01-12 07:46:43.0

01

约定

在收到Caliburn Micro中有关视图和ViewModel解析的反馈后,我们添加了新功能,以简化类型解析,同时保持驱动它的健壮的基于正则表达式的名称转换机制。为了更好地了解这些新功能以及类型解析通常如何在框架中工作,现在是详细描述框架支持的开箱即用的命名约定的适当时机。您现在应该已经知道,框架很大程度上依赖于命名约定,在类型解析中,需要考虑两种不同的命名约定:命名类型本身的约定和命名类型命名空间的约定。

类型名称的命名约定

如本文档其他部分所述,视图及其伴生ViewModel最常见的命名约定如下所示:

673f3b5488514a49c19b6826874471bd.png

因为我们认识到“视图”是一个抽象的术语,大多数应用程序的主要“视图”实际上是某种“页面”,所以我们认为框架将“页面”作为“视图”的同义词是很重要的。因此,该框架对该用例具有内置支持:

e48ab67f0410885c15a2b21df03f7fa0.png

如果仔细检查,您会发现上面两个约定之间存在细微的差异。“ViewModel”只是简单地添加到一个带有后缀名的“页面”中,以生成其ViewModel的名称。但是,只有“模型”添加到“视图”后缀名中,以生成其伴生ViewModel的名称。这种差异主要源于将某些东西命名为“MainViewModel”而不是“MainPageViewModel”的语义尴尬。因此,从“视图”后缀视图名称派生的视图模型的命名约定通过将视图模型命名为“MainViewModel”来避免冗余。

框架支持的标准命名约定的一个限制是,没有考虑到英语中的不同语言甚至不同术语。尽管“视图”和“视图模型”可以被普遍理解,因为它们都是Caliburn Micro致力于的MVVM设计模式的重要方面,但“页面”这样的词却不是。因此,一个健壮的框架至少允许通过定制来支持额外的“视图名称后缀”(例如“Pagina”、“Seite”、“Form”、“Screen”)。

多视图支持的命名约定

如文档约定部分所述,该框架旨在处理ViewModel和View之间的一对多关系。框架支持的标准公约如下:

2312d3461d4b6f00ae117664deea9b19.png

如前一节所述,ViewModel的名称可能包含也可能不包含“视图”后缀。这就是为什么显示为可选的原因。

类型的命名空间的命名约定

在.NET开发中,所有程序集都必须有一个默认命名空间。因此,最基本的用例中,视图和视图模型组件层都位于同一个用例中。这项公约可描述如下:

baac14dba1c890e71c3476d78a953f76.png

虽然许多应用程序的所有视图和视图模型都可能位于单个部件中,但通常的做法是在项目中的单独文件夹中组织视图和视图模型。因此,默认情况下,VisualStudio将把组件放在与这些文件夹相对应的单独名称空间中。由于项目文件夹类似于操作系统文件夹,因此项目子文件夹也可以嵌套在多层中。此常见用例的命名空间命名约定可以描述如下:

06f89cd2853046ae7fef306361ac5d1e.png

尽管上面的约定涵盖了嵌套名称空间的深度方面的许多可能性,但它确实在视图和视图模型的组织方案中假设了一种并行结构。此外,将视图和视图模型放置到单独的部件中也是很常见的,这使得跨不同部件进行并行组织的可能性更小。

02

最后

原文标题:Caliburn.Micro Xaml made easy

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

翻译:dotnet编程大全

C#技术群 : 添加小编微信mm1552923,备注:进群!

  相关解决方案