对于一个新项目,我最近被要求研究一种将与 UI 呈现相关的信息附加到 WPF 应用程序中的业务对象的方法。例如报告类:
class ExecutionReport
{
[Displayable(Bold, Background=Color.Red)]
public String OrderId{get; private set;}
[Displayable(Normal, HAlignment=Center)]
public String Symbol {get; private set;}
// this should be hidden as it doesn't have DisplayableAttribute
public String ClientOrderId {get; private set;}]
[Displayable(Normal, HAlignment=Right,
Format("If [Position] < 0 then Background=Color.Red"),
Format("If [Position] > 0 then Background=Color.Lime"),
DisplayFormat("+#;-#;0")]
public Int Position {get; private set;}
}
这对我来说是一种非常新的方法,因为在我处理过的大多数 wpf MVVM 应用程序中, View 和 View 模型都有明显的分离,我尽可能地努力将 UI 特定细节排除在 VM 之外。相反,我倾向于使用资源字典和应用于 View 层绑定(bind)的简单转换器来编写此代码。
我的问题是:有没有使用这种实现的 wpf/mvvm 框架?如果是这样,我很想知道它是如何实现的。
有什么明显的陷阱吗?我想到的第一件事是
更改通知(即 INotifyPropertyChanged 触发 View 更新)。现在实现起来会更难吗?
难以利用资源字典获取系统范围的值。例如,也许我想更改整个应用程序中使用的红色。我将不得不通过 ctrl + f 找到业务对象中使用它的每个地方并更改它,而不是能够修改单个 StaticResource
无法利用 DesignTime DataContexts
性能。似乎这需要大量使用反射,其性能可能不如典型的值转换器
我很想知道我在第二点和第三点上是否正确,或者这两点是否仍然可以实现?
最终我觉得这是一个糟糕的设计,我倾向于编写一个不同的实现来向感兴趣的一方展示我通常如何处理此类问题。只是想确保我没有遗漏一些明显的东西,这些东西实际上可能会使它更优雅。
最佳答案
IMO 这似乎是一个可怕的想法,它们看起来都像是应该作为 XAML 转换器实现的示例。
所有要点列表似乎都是避免这样做的正当理由。
注意:框架中有一组属性已经提供了一些 UI 功能(非常有限),请参阅 System.ComponentModel.DataAnnotations 命名空间。
关于c# - 使用属性定义 UI 的属性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25852761/