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

时间:2012-01-16 16:34:35

标签: naming-conventions viewmodel code-organization

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

问题是我的名字真的很长。依赖集通常具有以这种方式组成的名称:

  

视图模型名+生成器+ DependencySet

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

的视图模型
  

CategoryProviderDefinitionListViewModel

看起来像这样:

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

所以,我的构建器叫做

  

CategoryProviderDefinitionListViewModelBuilder

所以,我的依赖集叫做

  

CategoryProviderDefinitionListViewModelBuilderDependencySet

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

理想情况下,我可以将视图模型类组合在一起,将它们与使用它们的视图相关联。避免碰撞并使名称尽可能短,同时保持它们的意义,这将是一件好事。有没有人发现在这种情况下运行良好的命名约定/文件夹组织?

3 个答案:

答案 0 :(得分:9)

我一直在使用“ViewModel”后缀很长一段时间,说实话,有时我发现它是多余的。我认为只需将所有这些类分组到不同的命名空间就足够了。

我的理解是采用了这个约定来避免域模型和视图模型类之间的冲突(例如产品 vs ProductViewModel )。但是,由于您的视图模型是以屏幕命名的,因此您在域模型中使用同名的类是不太可能的。事实上,为什么你的域模型中有这样一个类应该是真的有问题! :)

因此,如果您将视图模型命名为 ViewProduct (以允许用户查看/编辑产品),则无需将其命名为 ViewProductViewModel 。看看我要去哪里?

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

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

如果您发现您的构建器依赖于可能的东西,这就是您试图隐藏在DependencySet后面的东西,那么它可能是其他地方设计气味的指示。如果类及其依赖项是以适当的面向对象的方式设计的,那么行为应该在各个类之间非常好地分布,并且没有类应该依赖于太多其他的东西。因此,将这些N依赖项隐藏在1类(DependencySet)下仅仅是处理症状而不是问题本身。

希望这有帮助:)

答案 1 :(得分:3)

我更喜欢使用“ DTO ”修复我的ViewModel名称。 (DTO代表数据传输对象,即一个只包含信息的对象)

这不仅是为了避免长名。但它也使我能够使用相同的名称,如用户,但它将被称为 UserDTO ,向我表明我正在使用属于我的对象ViewModel,从而避免命名冲突。

答案 2 :(得分:1)

我倾向于同意莫什。

ViewModel后缀在大多数情况下都是冗余的,虽然有时您可能有匹配的类名,但由于它们仅限于ViewModel命名空间,因此很容易管理。我还发现使用奇怪的命名空间别名会伤害我的大脑,而不是全面填充我的班级名称。

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

对于搜索结果和列表,我发现最好突破IEnumerable而不是IEnumerable。后者通常意味着您最终得到一个用户视图模型类,该类成为整个项目可能需要或可能不需要的所有用户属性的转储基础。这是值得注意的重要事项之一,如果你发现自己有这样的课程,那么你已经离开了某个地方。保持您的观点和视图模型的描述性和具体性。如果您有许多类似的视图模型,问题可能是更大的设计问题;一些设计师倾向于重新发明而不是重用现有的图形结构。