01

—

约定

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

类型名称的命名约定

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

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

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

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

多视图支持的命名约定

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

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

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

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

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

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

02

—

最后

原文标题：Caliburn.Micro Xaml made easy

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

翻译：dotnet编程大全

C#技术群 : 添加小编微信mm1552923，备注：进群！