对 MVVM 模式的反对是缺乏 IDE 支持 - 有任何框架对此有帮助吗？
我们的一些开发人员不喜欢 MVVM 中的命令，因为 VS2010 IDE 不支持帮助您从 xaml 中的命令绑定导航到实现该行为的实际代码。通过代码隐藏，您可以右键单击并选择“导航到事件处理程序”。 我们正在与大约 4 名开发人员一起启动一个新项目，但我们通常将工作划分为功能区域，而不是 Ux 和业务逻辑，因此每个开发人员都在 xaml 和视图模型/域中工作以实现所需的功能。
你们认为这是采用 MVVM 的障碍吗？
有哪些框架在这方面有帮助吗？
是否有任何提示/技巧可以满足导航需求？
也许我们应该尝试在用户体验和应用程序逻辑之间划分工作？
感谢您的任何想法。
Some of our developers don't like the commanding in MVVM because there is no support in VS2010 IDE to help you navigate from the Command binding in xaml to the actual code implementing the behavior. With code-behind, you can right-click and select Navigate to Event Handler.
We're starting a new project with about 4 developers but we typically divide the work into functional areas, not Ux and business logic so each developer is working in the xaml and the viewmodel/domain to implement the functionality needed.
Do you guys consider this a hindrance to adoption of MVVM?
Do any of the frameworks help in this regard?
Are there any tips/tricks that facilitate that navigation need?
Maybe we should try splitting work between Ux and app logic?
Thanks for any ideas.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对我来说这听起来像是抱怨，而不是对 Commands 或 MVVM 的实际批评。实现和使用MVVM并不需要花费太多精力。我从来没有使用过框架来实现MVVM。
我总是将命令放在视图模型类的顶部，然后是公共属性、构造函数和函数。
如果您在视图模型中找不到它们，则可能是您的文件太长。超过1500行了吗？如果是这样，请考虑将其分成多个类。
Sounds like whining to me, rather than actual criticism of Commands or MVVM. It doesn't take much effort to implement and use MVVM. I haven't ever used a framework to implement MVVM.
I always put my Commands at the top of my viewmodel classes, followed by public properties, the constructor and functions.
If you're having trouble finding them in your viewmodel, maybe your file is too long. Is it over 1500 lines? If so consider breaking it up into multiple classes.
没有一个框架可以帮助解决这个问题，因为它通常不是一个问题。如果您想使用 MVVM，我建议重新组建团队，以便按照 MVVM 建议的方式划分工作。
我主要在虚拟机中工作，并且 XAML 从来没有遇到过任何问题。 ……因为我几乎从来不碰它。对于设计我们观点的人来说，情况正好相反。他几乎完全使用 XAML 进行工作，并且不编写太多 C# 代码。
None of the frameworks help with this problem because it's not usually a problem. If you want to use MVVM, I would suggest reworking the team so that the work is split the way that MVVM suggests.
I work primarily in VMs and I never have any trouble with XAML. ...Because I almost never touch it. The inverse is true for our guy who designs our views. He works almost entirely in XAML and doesn't write much C# code.