问题 UI数据绑定:替代方案和未来


UI数据绑定也称为从应用程序的商业层/数据模型到UI以及从UI返回到数据模型的信息/数据传输,接口被语言和框架设计者稍微忽略一点。

今天软件系统处理的几乎所有信息都必须在处理链的某个点上呈现给人类用户,我们从编程系统获得的向用户提供信息的支持主要包括难以维护的传输方法,一些系统使用反射没有编译时验证(“propertychanged”任何人?),或者是自组织代码生成器。

我的意思是Erik Meijer,Anders Hejlsberg和他们的团队。我们付出了巨大的努力来解决数据库,XML和代码之间的阻抗不匹配问题......但主要是将UI排除在外。 (是的.net有数据绑定,但尝试使用它然后让我们谈谈一个真正的解决方案) 重点是:不将数据绑定作为一种语言f.e的第一类特征处理的理性是什么?为什么今天我们的工具中只有这么有限(或没有)支持MVC / MVP模式?

请提供有关可用替代概念的评论,提示和指示,甚至可能在该领域正在进行中。是否有任何新的创意和新想法?任何有用的框架,支持数据绑定的语言概念,以及可能帮助您在应用程序或系统中处理数据绑定的工具?


1112
2019-06-01 00:46:05


起源



答案:


虽然WPF绑定太复杂,但它结合了XPath和普通.Net绑定的特性,并且非常灵活,但是当它变得复杂时非常难以调试,而且非常冗长 - 一段代码需要多少IValueConverter?

来自WPF的DependencyObject非常出色 - 一个可以合理地管理内存的属性,内置了变更通知 - 这是一般的绑定和属性的良好开端。


6





Cocoa和Objective-C中的数据绑定非常活跃。部分原因是因为它建立在键值编码和键值观察的基础之上,这是Cocoa中非常可靠且经过深思熟虑的特性。它也很好地集成了Apple正在开发的许多新技术,例如Core Data。


2





其他支持数据绑定的框架是Adobe Flex和Microsoft的WPF。


1





WPF中的数据绑定和UI模型简直令人惊叹。您可以绑定到对象的方法,异步绑定,单向绑定(从源到目标,反之亦然)或双向绑定,并绑定到屏幕上的其他UI元素。

您可以指定DataTemplates,它控制特定类型的显示方式。您可以定义触发器,允许UI根据绑定对象(或UI中的其他位置)的更改进行更改。简而言之,如果您觉得缺少UI /绑定表示的状态,您应该真正看看WPF。

这是最近的一次 岗位 这说明了WPF的强大功能,使用基本结构可以显示带有坐标的地图。


1



是的,WPF已经根据反射和连接字符串常量的方式将.net数据绑定为前进的方法。一旦应用程序变得比酷样本更大,这往往会有问题。在那里,您需要更多的应用程序编译时间验证。 - pointernil


答案:


虽然WPF绑定太复杂,但它结合了XPath和普通.Net绑定的特性,并且非常灵活,但是当它变得复杂时非常难以调试,而且非常冗长 - 一段代码需要多少IValueConverter?

来自WPF的DependencyObject非常出色 - 一个可以合理地管理内存的属性,内置了变更通知 - 这是一般的绑定和属性的良好开端。


6





Cocoa和Objective-C中的数据绑定非常活跃。部分原因是因为它建立在键值编码和键值观察的基础之上,这是Cocoa中非常可靠且经过深思熟虑的特性。它也很好地集成了Apple正在开发的许多新技术,例如Core Data。


2





其他支持数据绑定的框架是Adobe Flex和Microsoft的WPF。


1





WPF中的数据绑定和UI模型简直令人惊叹。您可以绑定到对象的方法,异步绑定,单向绑定(从源到目标,反之亦然)或双向绑定,并绑定到屏幕上的其他UI元素。

您可以指定DataTemplates,它控制特定类型的显示方式。您可以定义触发器,允许UI根据绑定对象(或UI中的其他位置)的更改进行更改。简而言之,如果您觉得缺少UI /绑定表示的状态,您应该真正看看WPF。

这是最近的一次 岗位 这说明了WPF的强大功能,使用基本结构可以显示带有坐标的地图。


1



是的,WPF已经根据反射和连接字符串常量的方式将.net数据绑定为前进的方法。一旦应用程序变得比酷样本更大,这往往会有问题。在那里,您需要更多的应用程序编译时间验证。 - pointernil


在Python中,您可以使用 Enthought Traits 为了这。您定义了一个模型,该模型已包含所有知识和逻辑,因此您可以使用一行代码为其创建编辑器。


1





我正处于移植项目的后期阶段,将AppMaker生成的代码从基于C的Macintosh GUI转移到WPF。

AppMaker的代码生成风格远远超过了它的时代 - 15年前,它生成了基于模型的代码,其中包含数据绑定和基于属性的方法。 C代码的缺点是所有管道都暴露在外。

这个项目非常吸引人 - 将一个纯粹的绑定和命令结构(尽管是丑陋的代码)的架构带到了WPF。我其实写了一个 新的AppMaker代码生成器 将原始对象模型导出到XML,并从那时起使用Ruby生成XAML,C#和C ++ / CLI。

我对WPF中的数据绑定模型的效果印象非常深刻,尽管找到XAML与C#中放置内容的最佳位置很有意思。如在a。中所解释的 最近的DevJam 演示文稿,我们决定采用三层方法

  1. 非常精简的XAML造型,
  2. C#用于绑定,
  3. 用于ViewModel实现的C ++ / CLI。

我从回来开始就是一个有约束力的粉丝 - 我的C ++ OOFILE框架首先使用绑定方法来简化数据库 与表格的联系 在1997年左右的不同GUI框架中。

作为一个兴趣点,在我编写Windows代码生成器的多年合作之后,我从最初的美国所有者手中收购了AppMaker。看起来几乎令人难以置信的是,位于西澳大利亚州珀斯的一家小公司,拥有复杂的AppMaker生成的GUI端口,应该会发现世界上剩下的AppMaker专家居住在30英里外!


1





Eclipse的UI层SWT / JFace最近已经扩展了UI数据绑定功能。看到 http://wiki.eclipse.org/index.php/JFace_Data_Binding


1