模型-视图-视图模型 (MVVM) 类和实例的名称应该有多详细？
一般来说，我更喜欢详细介绍 .NET 类和实例名称，但有时 (引用迈克·伍德豪斯的话）：
过于冗长往往会掩盖语法，而语法很重要。
我第一个感觉自己真正陷入过度冗长状态的地方是在 Silverlight 和 WPF 应用程序中实现模型-视图-视图模型 (MVVM) 模式。
例如，我从 EnumerableRange 模型对象开始：
public class EnumerableRange<T> : IEnumerable<T>
{
public T Start{ get; set; }
public T Stop{ get; set; }
public long Count{ get; set; }
...
}
然后，我想创建一个控件，允许我为用户输入显示此类。 因此，我创建了一对与视图相关的类：
- 一个 EnumerableRangeControlView UserControl（在 XAML 中）和
- 一个 POCO EnumerableRangeControlViewModel
现在，我分别在父 View 和 ViewModel 中使用这对类。 使用 MVVM，视图实例不需要名称，但我的 ViewModel 实例现在的名称类似于：
IndependentVariableEnumerableRangeControlViewModel。
事情开始失控了！ 你会怎么办？
In general, I prefer to be verbose with .NET class and instance names, but some times (to quote Mike Woodhouse):
Over-verbosity tends to conceal syntax, and syntax is important.
The first place I felt like I really strayed into the over-verbosity regime is upon implementing the Model-View-ViewModel (MVVM) pattern in Silverlight and WPF apps.
For example, I start with an EnumerableRange model object:
public class EnumerableRange<T> : IEnumerable<T>
{
public T Start{ get; set; }
public T Stop{ get; set; }
public long Count{ get; set; }
...
}
Then, I want to create a control that will allow me to surface this class for user input. Thus, I create a pair of view-related classes:
- an EnumerableRangeControlView UserControl (in XAML), and
- a POCO EnumerableRangeControlViewModel
Now, I use this pair in the parent View and ViewModel, respectively. With MVVM the view instance doesn't need a name, but my ViewModel instance is now named something like:
IndependentVariableEnumerableRangeControlViewModel.
Things are starting to get out of hand! What would you do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议如下：
从 View/ViewModel 类和实例名称中完全删除“Control”一词。 “View”和“ViewModel”清楚地说明了类的用途。
（可选）始终采用约定来使用“VM”后修复 ViewModel 实例。
（
在上面的示例中，实例名称
变得更具可读性
I propose the following:
Drop the word "Control" from View/ViewModel classes and instance names altogether. "View" and "ViewModel" clearly state the class purposes.
(Optional) Consistently adopt a convention to post-fix ViewModel instances with "VM".
In the example above, the instance name
becomes a much more readable