WPF - XAML 中的 Lambda 评估
我正在 WPF 中编写一个应用程序。将我所有的转换器变成简单的东西变得很烦人。
我环顾四周，发现了 WPFix。它看起来不错，但近一年来没有发布任何版本，看起来已经被放弃了。
有人用过这个吗？稳定吗？有没有人对不同的解决方案有任何建议，以允许在 XAML 中使用 Lambda（或者避免使用大量转换器）？
I am writing an app in WPF. It is getting tiresome making all my converters for simple stuff.
I looked around and found WPFix. It seems nice, but has not had any releases in almost a year and is looking abandoned.
Has anyone used this? Is it stable? Does anyone have any recommendations for a different solution to allow Lambdas in XAML (Or otherwise avoid lots of Converter)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要跳到问题的最后部分：这是关于 WPF Disciples 的讨论提出了 MV-VM 消除了对转换器的大部分需求； ViewModel 应以适合该视图的方式将数据呈现给该视图。
为什么要编写一个单独的类，实现 IValueConverter，充实
Convert和ConvertBack方法，只是为了将 Int32 转换为 Color，而您可以让 VM 公开 Color财产放在第一位，对吗？我想这个问题的答案取决于你对视图和视图模型之间的分离有多虔诚......我开始认为视图模型应该简单地呈现模型并将业务规则应用于它，并且应该是“视图不可知论” '，也许需要一个中间层来专门为您的视图操作 ViewModel，因此，如果您更换了视图（无论出于何种原因！），您不需要重写您的 VM，只需要重写“中间”层。然后我想到 WPF 已经有了 ValueConverters 形式的中介...
所以总结一下：您可以通过简单地让您的 VM 公开一个转换器的属性来消除转换器的大量重复开发。首先选择适当的类型...
现在您需要决定是否想要...
只是我的 2c 价值...:)
To skip to the last part of your question: This is a discussion on WPF Disciples that puts forward the notion that M-V-VM negates most of the need for converters; that the ViewModel should present the data to the View in a way that is appropriate for that View.
Why write a separate class, implement IValueConverter, flesh out the
ConvertandConvertBackmethods, just to get an Int32 to a Color, when you could just have the VM expose a Color property in the first place, right?I guess the answer to that depends on how religious you are about separation between the View and the ViewModel... I'm starting to think that the ViewModel should simply present the Model and apply business rules to it, and should be 'View Agnostic', and maybe an intermediary layer is required to manipulate the ViewModel specifically for your View, so if you ever swap out your View (for whatever reasons!) you don't need to rewrite your VM, just the 'intermediary' layer... then it occurred to me that WPF already has such an intermediary in the form of ValueConverters...
So to summarise: You could remove lots of repetitive development of Converters by simply having your VM expose properties of an appropriate type in the first place...
Now you need to decide if you want to...
Just my 2c worth... :)
在查看了作者在第一篇博客文章中的示例后，我认为他在 WPF 和 XAML 方面有些忽略了要点。
当然，编写简单的转换器可能很烦人，但是当您将 lambda 嵌入到 XAML 中时，您就开始走上拥有整体视图的道路。要使用作者自己的呈现短日期的示例，一旦您开始使用 lambda 进行操作，那么当您有需要不同格式（即 mm/dd/yy、dd/mm/年、年/月/日）。如果将它们保留为转换器，那么它们可以与资源组件一起容纳并随意交换，而无需更改视图。同样的概念也适用于因用户文化而改变的任何其他事物。
显然 WPFix 库在某些方面可能很酷，但每个人对它的看法都会略有不同。但是，当您编写这些转换器时，请将 XAML 的声明性视为积极的而不是消极的 - 它为您提供了数据的实际表示和数据的表示准备之间的抽象。如果您正在编写一个简单的应用程序或快速原型，那么将这两者混合在一起（View 和 ViewModel）可能没问题，但对于大规模生产，您会发现保持这两者之间的分离是有益的。
After looking at the author's examples in his first blog post, i think he has missed the point somewhat with WPF and XAML.
Sure it can be tiresome writing simple converters, but when you embed lambdas into your XAML you are starting down the road of having a monolithic view. To use the author's own example of presenting short dates, as soon as you start doing it with a lambda then you have to change your view when you have a user that requires a different format (i.e. mm/dd/yy, dd/mm/yy, yy/mm/dd). If these were kept as converters then they could be housed with a resource assembly and swapped out at will without changing the view. The same concept goes for anything else that would change due to the culture of the user.
Obviously the WPFix library could be cool for some things, and everybody will have a slightly different opinion on it. But as you write those converters, think of the declarative nature of XAML as a positive instead of a negative - it gives you abstraction between the actual presentation of the data and the preparation of that data for presentation. If you are writing a simple app or a quick prototype then mixing these two together (the View and the ViewModel) might be fine, but for larger scale productions you would find it beneficial to maintain a separation between those two.
您是对的，自 2008 年以来就没有正式版本。但是，最后一次 源代码签入 于 2009 年 10 月 22 日完成。
You are correct that there have been no official releases since 2008. However, the last source code check-in was done on October 22, 2009.