不久前,我开始为WPF编写一个停靠库(类似于Avalon).当时我的目标是用MVVM方式进行学习.为了让事情运转起来,我决定首先设计视图和模型部件,并认为我稍后会在其间插入一些视图模型.现在我完成了所有的视图和模型:视图获取模型并直接与它交谈,而模型公开了一系列事件以盲目地通知他们的听众.此外,它的每个视觉方面都可以在XAML中进行重新设置/模板化.事情进展顺利.现在我被困在视图模型部分.
根据这种库的性质(内容更改并动态重新创建),还有很多代码仍然需要在视图的代码隐藏部分中编写,我并没有真正看到有什么好处.还为每个视图编写了一堆视图模型类.可能在几个地方使用一些绑定/命令会很方便,但我并不认为它弥补了完成纯MVVM设计所需的所有重构.
我确实理解MVVM设计的优点,我非常喜欢它,但在这种情况下,我无法看到视图模型如何为整个事物添加任何值.
任何想法,建议或更正将不胜感激.
提前致谢.
Ree*_*sey 12
这里的部分问题是你正在有效地创建一个控件库 - 因此,你正在开发一些完全属于MVVM中"View"的东西.虽然你可以强制推出一个MVVM-ish"模型",但它可能会使你的代码变得混乱.
请记住,MVVM旨在将特定于应用程序的逻辑和数据桥接到View - 但在这种情况下,当您编写控件库时,您的"逻辑和数据"就是View本身.将视图与模型分开在这里没有多大意义 - 因为模型实际上是View的一部分.
我并不是说清楚地分离关注点并不重要,但在这种情况下,在MVVM方面考虑这一点可能不太合适.模型并不与View分开,并且尝试将其完全分离并在其间添加另一层抽象可能会增加复杂性而无法获得.
如果您正在创建自定义控件库,那么目标不应该是使用MVVM编写它,而是确保在MVVM应用程序中使用时控件可以正常工作.这通常意味着确保您的控件都为所有内容和设置公开适当的依赖属性,并且它们可以干净地使用数据绑定等.事实上,事件通常不是必需的,至少没有那么多,并且具有单独的"模型类"层次结构将妨碍用户 - 用户希望能够放弃您的控件并直接绑定到该控件上的属性,这几乎可以保证您的控件将具有代码.
因为你正在使用WPF或Silverlight而自动假设MVVM是合适的是一个谬论.MVVM适用于某些类型的应用程序,但控件(或控件库)不一定是其中之一.
| 归档时间： |
|
| 查看次数： |
230 次 |
| 最近记录： |