什么时候不应该使用 MVVM?

发布于 2024-10-10 23:00:01 字数 168 浏览 2 评论 0原文

我最近开始使用 MVVM 模式。我在几个项目中使用过它,对于每一个新项目,我开始发现它非常适合该新项目。

现在我开始问自己是否存在最好使用 MVVM 的情况。或者它是一个可以在任何地方使用的漂亮图案吗?

您能否描述一下 MVVM 不是最佳选择的几种场景?

I have started using MVVM pattern recently. I have had several projects where I used it and with every new one, I start to see that it will fit great within that new project.

And now I start to ask myself are there situation when it's better NOT to use MVVM. Or is it such a nice pattern which you can use anywhere?

Could you please describe several scenarios where MVVM wouldn't be the best choice?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

为人所爱 2024-10-17 23:00:01

我可以想到两种情况下我不会使用 MVVM。

一是应用程序是否足够简单,我不需要将视图模型和模型分开。如果我实现 INotifyPropertyChanged 和一个或两个 RelayCommand ,我的类会不会太混乱?如果没有,我可能会跳过创建单独的类的步骤。或者我可能只是想要一个视图模型来模拟功能性 UI,并担心如果客户端愿意的话如何实现实际的后端功能。

另一种是当我需要足够高的性能并且视图中有足够的对象时,我需要编写直接操作 WPF 对象的代码。我实际上并没有对它进行基准测试来确定,但我可以相当肯定地通过迭代包含它们的数组并直接修改它们的 TranslateTransform 来绘制 1000 个移动粒子(如果这确实是最快的方法)定位它们)将比修改它们的基本属性并通过绑定来完成更快。

I can think of two circumstances under which I wouldn't use MVVM.

One is if the application's simple enough that I don't need a separation between the view model and the model. Does it muck up my class too much if I implement INotifyPropertyChanged and a RelayCommand or two? If not, I might skip the step of creating a separate class. Or I may just want a view model to mock up a functional UI, and worry about implementing actual back-end functionality if the client bites.

The other is when I need high enough performance, and there are enough objects in the view, that I need to write code that manipulates WPF objects directly. I haven't actually benchmarked it to be sure, but I'm be reasonably certain that drawing 1000 moving particles by iterating through an array containing them and modifying their TranslateTransform directly (if indeed that's the fastest way to position them) is going to be faster than modifying their base properties and having binding do it.

随风而去 2024-10-17 23:00:01

只有当 MVVM 工具在某个特定时刻使用次数不多,然后就永远不会使用时,我才不会使用 MVVM。

在很多“小”项目中,我一开始没有,后来改用了MVVM。在我看来,它使项目更加干净,并为我的所有项目提供了类似的结构。如果客户有一个小请求,这对我快速更改一些旧代码中的某些内容有很大帮助。我不会浪费太多时间来定位。

另一个优点是更容易保持我的库干净,因为我可以专注于一种技术,因此有更多的时间来维护和扩展。

I only do not MVVM if its a tool that is not used more than at a specific moment and then never ever.

In many "small" projects, I have begun without, and later on, I have changed to MVVM. It makes the projects IMO much more clean and gives all my projects a similar structure. This helps me a lot to change quickly some things in some elder code if a client has a small request. I don't loose much time to me orientate.

Another advantage is that it's easier to hold my libraries clean, because I can focus on one technique and have therefore more time to maintain and extend.

童话 2024-10-17 23:00:01

这完全取决于您想做什么。

就像这些人所说的那样,如果您正在创建一个不需要大量测试等的小工具或项目,那么 MVVM 就有点大材小用了。

可以说,MVVM 的主要优点是它使代码单元可测试,因为它从视觉层中抽象出来。对于需要可靠且由客户等(而不仅仅是您自己作为最终用户)使用的大型项目,MVVM 是一个很好的设计模式。

我想简而言之 - 如果你只是创建一个小项目来搞乱,那么 MVVM 就像尝试用火箭筒杀死一只蚂蚁:)

It all depends on what you want to do.

Like the guys have said, if you are creating a small tool or project that will not need extensive testing etc then MVVM would be overkill.

Arguably MVVM's main advantage is that it makes the code unit testable as it abstracts away from Visual Layer. For large projects that need to be reliable and are to be used by customers etc (and not just yourself as the end user) then MVVM is a good design pattern to use.

I guess in a nutshell - if you are simply creating a small project to mess around with then MVVM would be like trying yo kill an ant with a bazooka :)

野侃 2024-10-17 23:00:01

对我来说,当你想做一个小项目或者从来不打算让它在多种方式(WPF/Silverlight/WEB/Dll)下运行时,最好不要使用它,那么 MVC 就足够了。

For me it's best to not use it when you want to do a small project or never plan to make it run under several ways (WPF/Silverlight/WEB/Dll), then MVC is enough.

你不是我要的菜∠ 2024-10-17 23:00:01

简短回答:如果您不使用 WPF/Silverlight/我所知道的具有强大自动绑定功能的任何技术,请不要使用 MVVM。

长答案:没有其他模式比 WPF/Silverlight 中的 MVVM 更能促进单元测试。
我建议您看一下我的另一个答案:为什么我应该在 Silverlight 应用程序中使用 MVVM?

Short Answer: Don't use MVVM if you are not using WPF/Silverlight/any technology I know with powerful automatic binding.

Long Answer: No other pattern facilitates unit testing better than MVVM in WPF/Silverlight.
I would suggest you take a look at another of my answer : Why should I use MVVM in Silverlight app?

眼泪都笑了 2024-10-17 23:00:01

您可能想看看 关于 MVVM 开发的发泄 Silverlight 论坛,其中讨论了 MVVM 的一些优点和缺点。

You may want to have a look at A vent about MVVM development at the Silverlight forum where some of the benefits and shortcomings of MVVM are discussed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文