我在术语冲突中挣扎，无法解决一个好的解决方案。也许其他人遇到了这个问题。
我正在重建现有的WinForms应用程序以使用WPF。我将在新应用程序中使用MVVM模式。我的旧应用程序大量使用了ADO。具体来说，我有包装Row对象的DataRow对象。当我想定义行中的哪些列可以出现在UI的特定上下文中时，该定义位于RowView对象中。
从概念上讲，“ View ”是一个合适的术语-单个基础DataRow可以具有多个Row对象，每个对象都使用RowView对象定义其列子集，访问权限等，就像SQL数据库中的 View 一样。 ColumnView的RowView集合中的ColumnViews对象包含有关该特定 View 中每一列的表示形式的元信息。
这一切都用湿的撞击击中了MVVM模式。在MVVM中，“ View ”的含义有所不同:它表示对象的UI表示。就MVVM而言，我的应用程序的RowView不是 View 。对于MVVM，实际上并没有一个RowView对象，但是有一个底层的RowViewModel支持用户界面和特定Row对象之间的交互逻辑，并且还为行的每一列提供了一个底层的ColumnView对象。
通常，术语错误是由类别错误引起的，但在这种情况下，我认为类别正确。问题在于不同的上下文对不同的事物使用相同的名称。
发生这种情况时，最幼稚的答案是“命名空间”，但是尽管使用命名空间消除这些术语的歧义在技术上肯定会奏效，但我对此深表怀疑，这将使新开发人员在这段代码上tum绊绊时会遇到的困惑。
另一种可能性是将Row对象的名称更改为其他名称。就像，我可以在模型中使用“行”和“列”，在 View 和 View 模型中使用“记录”和“字段”。因此，我可以从Record和Row组成RowView，并从每个列值和Field组成ColumnView。然后，我可以将RecordViewModel和FieldViewModel对象暴露给WPF，并且UI开发人员将永远不必知道存在诸如RowView和ColumnView对象之类的东西。但是这种臭味也是。
有人在重建使用MVVM的软件时遇到过此类问题吗？你到底做了什么？
最佳答案
在这种情况下，我倾向于以匈牙利语相反的方式附加内容。
我个人使用 namespace 和少量约定。我知道我的模型在哪里以及如何使用它们，因为我在整个应用程序，VM和 View 中始终使用它们。我可以通过使用或引用方式，引用方式来区分View，ViewModel或Model之间的区别，我想您也会发现。
但是，如果您发现这会影响新开发人员的加入，或者您在提出一致约定方面遇到困难，则可以尝试使用类似匈牙利语的命名约定来区分类型。
关于wpf - 重构现有代码以使用MVVM模式时，如何解决此术语困惑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2173581/