关于视图模型的命名约定以避免长名称答案

【问题标题】：Naming Conventions Regarding View Models to Avoid Long Names关于视图模型的命名约定以避免长名称
【发布时间】：2012-02-11 13:52:10
【问题描述】：

我正在为我的 ASP.NET MVC 应用程序中的每个屏幕创建视图模型。我将创建视图模型的所有逻辑都放在 builder 类中。通常，将数据对象转换为视图模型有特殊的逻辑，包括聚合、过滤和排序。每个构建器都被传递一个依赖集，它是一个包含每个依赖（存储库、其他构建器等）的属性的对象。

问题是我的名字变得真的长了。依赖集通常有一个这样组成的名称：

view-model-name+Builder+DependencySet

视图模型的名称通常由您当前所在的位置和孩子组成。例如，我的系统对提供者定义进行了分类。因此，为了在一个类别下显示提供者定义，我有一个名为：

CategoryProviderDefinitionListViewModel

它看起来像这样：

public sealed class CategoryProviderDefinitionListViewModel
{
    public long CategoryId { get; set; }
    public string CategoryName { get; set; }
    public ProviderDefinitionViewModel[] ProviderDefinitions { get; set; }
}

所以，我的建造者被称为

CategoryProviderDefinitionListViewModelBuilder

所以，我的依赖集被称为

CategoryProviderDefinitionListViewModelBuilderDependencySet

这几乎不适合整个屏幕。我可怜的手指累了。此外，有些屏幕几乎显示相同的数据，因此它们的视图模型名称几乎相同。当我浏览我的文件夹时，很难找到我正在寻找的特定视图模型类。

理想情况下，我可以将我的视图模型类组合在一起，将它们与使用它们的视图相关联。避免冲突并使名称尽可能短，同时保持它们的意义会很好。有没有人找到在这种情况下运作良好的命名约定/文件夹组织？

【问题讨论】：

标签： naming-conventions viewmodel code-organization

【解决方案1】：

我一直在使用“ViewModel”后缀，老实说，有时我觉得它是多余的。我认为只需将所有这些类分组到不同的命名空间就足够了。

我的理解是采用这种约定是为了避免域模型和视图模型类之间的冲突（例如 Product 与 ProductViewModel）。但是，由于您的视图模型是以屏幕命名的，因此您的域模型中不太可能有同名的类。事实上，为什么你的领域模型中有这样一个类应该是值得怀疑的！ :)

因此，如果您将视图模型命名为 ViewProduct（以允许用户查看/编辑产品），则无需将其命名为 ViewProductViewModel .看看我要去哪里？

因此，您的 Builder 类可以简单地称为 ViewProductBuilder 而不是 ViewProductViewModelBuilder。

关于你的依赖集，我不确定你背后的理由是什么。但在我看来，这似乎没有必要。如果您的构建器对其他对象有依赖关系，您需要在构建器的构造函数中注入依赖关系，而不是将它们封装到另一个类（DependencySet）中然后传递它们。

如果你发现你的构建器依赖于太多东西，而这正是你试图隐藏在 DependencySet 后面的东西，那么它可能表明其他地方存在设计气味。如果类及其依赖项以适当的面向对象方式设计，则行为应该在各个类之间很好地分布，并且任何类都不应该依赖于太多其他事物。因此，将这 N 个依赖项隐藏在 1 个类（DependencySet）下只是治疗症状而不是问题本身。

希望有帮助:)

【讨论】：

【解决方案2】：

我更喜欢使用“DTO”对我的 ViewModel 名称进行后修复。（其中 DTO 代表数据传输对象，即只包含信息的对象）

这不仅是为了避免长名称。但它也使我能够使用与 User 等相同的名称，但它将被称为 UserDTO，这表明我正在使用属于我的一部分的对象ViewModel，从而避免命名冲突。

【讨论】：

a DTO is a different thing though，首先，可以在同一个解决方案中拥有一个 DTO 和视图模型。
确实如此。如果出现这种情况，我可能还会选择不同的命名约定。但好点。

【解决方案3】：

我倾向于同意莫什的观点。

ViewModel 后缀在大多数情况下变得多余，虽然有时您可能有匹配的类名，但由于它们仅限于您的 ViewModel 命名空间，因此很容易管理。我还发现，使用奇怪的命名空间别名对我的大脑造成的伤害小于给我的类名添加后缀。

当然，在您的演示者/控制器中，您可能会遇到命名冲突，但这可能表明您需要更恰当地命名您的视图，例如不是用户，而是 ViewUser/EditUser。

对于搜索结果和列表，我发现最好使用 IEnumerable 而不是 IEnumerable。后者通常意味着您最终会得到一个用户视图模型类，该类会成为整个项目可能需要也可能不需要的所有用户属性的垃圾场。这是需要注意的大事之一，如果你发现自己有这样的课程，那么你已经偏离了轨道。保持您的视图和视图模型具有描述性和具体性。如果您有许多类似的视图模型，则问题可能是更大的设计问题；一些设计师倾向于重新发明而不是重用现有的图形结构。

【讨论】：