一些上下文:
想象一下,200多家开发公司最终建立了一个或多或少独立的架构团队/部门.由20多个"项目"/生产中不同规模的应用程序组成的软件组合由团队负责人/技术负责人负责,他们负责并负责项目"架构".
由于必须整合和控制架构并在整个系统上实现某些必要的大型返工,除了所有需要的知识交换之外,公司还决定建立一个架构部门.
什么是DO和DO不是这样的事业？
组成这样一个建筑团队的人是谁？
他们应该承担什么责任？
什么超出了他们的范围？
公司有哪些有用的过渡战略？
每当有人提到"建筑团队"时,如何防止那些歪歪扭扭的样子？
贵公司是否已成功进行此类更改？
为什么会失败？
为什么成功？
这不应该是关于"什么是建筑师？"(这是非常密切相关的)的讨论.
真正有趣的观点是可接受的/现实的,甚至是无摩擦的方式来安装这样一个团队,当然除了一些关于战斗的警告,最好不要开始.
UI数据绑定也称为从应用程序的商业层/数据模型到UI以及从UI返回到数据模型的信息/数据传输,接口被语言和框架设计者稍微忽略.
今天软件系统处理的几乎所有信息都必须在处理链的某个点上呈现给人类用户,我们从编程系统获得的向用户呈现信息的支持主要包括难以维护的传输方法,一些系统使用反射没有编译时验证("propertychanged"任何人？),或者是自组织代码生成器.
我的意思是Erik Meijer,Anders Hejlsberg和他们的团队为解决数据库,XML和代码之间的阻抗不匹配付出了巨大的努力......但是大部分都忽略了UI.(是的.net有数据绑定,但尝试使用它,然后让我们谈谈一个真正的解决方案)重点是:什么是不将数据绑定作为语言fe的头等特征处理的理性？为什么今天我们的工具中只有这么有限(或没有)支持MVC/MVP模式？
请提供有关可用替代概念的评论,提示和指示,甚至可能在该领域正在进行中.是否有任何新的创意和新想法？任何有用的框架,支持数据绑定的语言概念,以及可能帮助您在应用程序或系统中处理数据绑定的工具？