我正在努力解决术语冲突，无法找到一个好的解决方案。也许其他人有这个问题。
我正在重建现有的WinForms应用程序以使用WPF。我将在我的新应用程序中使用MVVM模式。我的旧应用程序广泛使用ADO;具体来说，我有Row个包裹DataRow个对象的对象。当我想定义行中的哪些列可以出现在UI中的特定上下文中时，该定义存在于RowView对象中。
从概念上讲，“view”是一个合适的术语 - 单个底层DataRow可以有多个Row个对象，每个对象使用RowView对象来定义其列的子集，访问权限等，就像SQL数据库中的视图一样。 ColumnView的{{1}}集合中的RowView个对象包含有关该特定视图中每列的显示的元信息。
这一切都是以湿砰砰声击中MVVM模式。在MVVM中，“视图”意味着不同的东西：它表示UI对象的呈现。就MVVM而言，我的应用程序ColumnViews不是视图。对于MVVM，实际上没有RowView对象，但是有一个底层RowView支持UI和特定RowViewModel对象之间的交互逻辑，以及底层Row。 1}}每个行列的对象。
通常，术语混淆来自类别错误，但在这种情况下，我认为我的类别是正确的;问题是不同的上下文对不同的东西使用相同的名称。
当发生这种情况时，天真的答案就是“命名空间”，但是使用命名空间消除这些术语的歧义肯定会在技术上起作用，我严重怀疑它会解决新开发人员在遇到绊脚石时遇到的困惑在这段代码中有一点。
另一种可能性是将ColumnView对象的名称更改为其他名称。就像，我可以在模型中使用“row”和“column”，在视图和视图模型中使用“record”和“field”。因此，我可以从Row和Record撰写Row，并从每个列值和RowView撰写Field。然后我可以让ColumnView和RecordViewModel对象暴露给WPF，并且UI开发人员永远不必知道存在FieldViewModel和RowView对象之类的东西。但这种情况也很糟糕。
有没有其他人在重建软件以使用MVVM时遇到此类问题？你到底做了什么？
答案 0 :(得分：1)
我更愿意在这些情况下附加一些东西，而是采用反向的匈牙利符号方式。
我个人使用名称空间和一小部分约定。我知道我的模型在哪里以及如何使用它们因为我在整个应用程序以及我的VM和视图中始终如一地使用它们。我可以根据使用或引用的方式和位置来区分View，ViewModel或Model之间的区别，我想你也会发现它也是如此。
但是，如果您发现这会影响您对新开发人员的登机，或者您无法提出一致的约定，那么您可以尝试匈牙利式的命名约定来区分类型。