在重构现有代码以使用 MVVM 模式时，如何解决这种术语混乱？
我正在努力解决术语冲突，无法找到一个好的解决方案。也许其他人也遇到过这个问题。
我正在重建现有的 WinForms 应用程序以使用 WPF。我将在我的新应用程序中使用 MVVM 模式。我的旧应用程序大量使用了 ADO；具体来说，我有包装 DataRow 对象的 Row 对象。当我想要定义行中的哪些列可以出现在 UI 的特定上下文中时，定义位于 RowView 对象中。
从概念上讲，“视图”是一个合适的术语 - 单个底层 DataRow 可以有多个 Row 对象，每个对象使用一个 RowView 对象来定义它的列子集、访问权限等，就像 SQL 数据库中的视图一样。 RowView 的 ColumnViews 集合中的 ColumnView 对象包含有关该特定视图中每列的呈现方式的元信息。
这一切都对 MVVM 模式产生了巨大的冲击。在 MVVM 中，“视图”的含义有所不同：它表示对象的 UI 呈现。就 MVVM 而言，我的应用程序的 RowView 不是视图。对于 MVVM 来说，并不存在真正的 RowView 对象，但有一个底层 RowViewModel 支持 UI 和特定 Row 之间的交互逻辑code> 对象，以及每行列的基础 ColumnView 对象。
通常，术语混乱是由类别错误引起的，但在这种情况下，我认为我的类别是正确的；问题是不同的上下文对不同的事物使用相同的名称。
发生这种情况时，天真的答案是“命名空间”，但是虽然使用命名空间来消除这些术语的歧义在技术上肯定会起作用，但我非常怀疑它是否会解开新开发人员在偶然发现此代码时遇到的困惑一点点。
另一种可能性是将 Row 对象的名称更改为其他名称。就像，我可以在模型中使用“行”和“列”，在视图和视图模型中使用“记录”和“字段”。因此，我可以从 Row 和 RowView 组成一个 Record，并从每个列值和 Field 组成一个 Field >列视图。然后，我可以将 RecordViewModel 和 FieldViewModel 对象公开给 WPF，并且 UI 开发人员永远不必知道诸如 RowView 和ColumnView 对象已存在。但这种也太臭了。
有其他人在重建软件以使用 MVVM 时遇到过此类问题吗？你到底做了什么？
I'm struggling with a terminological conflict and can't figure out a good resolution. Maybe someone else has had this problem.
I'm rebuilding an existing WinForms application to use WPF. I'll be using the MVVM pattern in my new application. My old application makes extensive use of ADO; specifically, I have Row objects that wrap DataRow objects. And when I want to define what columns within a row can appear in a specific context in the UI, the definition lives in a RowView object.
Conceptually, "view" is an appropriate term for this - a single underlying DataRow can have multiple Row objects, each using a RowView object to define its subsets of its columns, access rights, etc, much as a view would in a SQL database. The ColumnView objects that in the RowView's ColumnViews collection contains metainformation about the presentation of each column in that specific view.
This is all hitting the MVVM pattern with a wet thud. In MVVM, "view" means something different: it means the UI's presentation of an object. My application's RowView isn't a view, as far as MVVM is concerned. To MVVM, there isn't really a RowView object as such, but there's an underlying RowViewModel that supports the interaction logic between the UI and a specific Row object, and an underlying ColumnView object for each of the row's columns.
Usually, terminological confusion emerges from category errors, but in this case I think I've got the categories right; the problem is that different contexts use the same name for different things.
The naive answer when that happens is "namespaces," but while using namespaces to disambiguate these terms will certainly work technically, I have serious doubts that it will unravel the confusion a new developer experiences when stumbling across this code one bit.
Another possibility is changing the name of the Row object to something else. Like, I could use "row" and "column" in the model, and "record" and "field" in the view and view model. So I could compose a Record from a Row and RowView, and a Field from each column value and ColumnView. Then I could have RecordViewModel and FieldViewModel objects that get exposed to WPF, and the UI developer would never have to know that such things as RowView and ColumnView objects existed. But this kind of stinks too.
Has anyone else run across this kind of problem while rebuilding software to use MVVM? What the heck did you do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这些情况下，我更愿意以反向匈牙利表示法方式附加内容。
我个人使用命名空间和一小部分约定。我知道我的模型在哪里以及如何使用它们，因为我在整个应用程序以及我的虚拟机和视图中一致地使用它们。我可以通过使用或引用的方式和位置来区分视图、视图模型或模型之间的区别，我想您也会发现您也这样做。
但是，如果您发现这影响了新开发人员的入职，或者您在制定一致的约定方面遇到困难，则可以尝试使用匈牙利式命名约定来稍微区分类型。
I would prefer to append things in these cases, sort of in a reverse Hungarian notation fashion.
Personally I use namespaces and a small collection of conventions. I know where my models are and how they are used because I use them consistently throughout the application as well as my VMs and Views. I can tell the difference between a View, ViewModel, or a Model by how and where it is used or referred to and I think you will find that you do, too.
However, if you find that this affects your on boarding of new developers or you are having trouble coming up with consistent conventions, you can try the Hungarian-esque naming conventions to differentiate types a little.