3

征求关于模式或最佳实践的反馈/想法，以解决我多年来见过几次的情况，但我还没有找到任何一种解决方案，可以按照我想要的方式解决它。

这是背景。

公司有 3 个应用程序支持 3 个相互关联的独立“业务线”。其中两个应用程序实际上是从原件复制/粘贴。应用程序需要能够以不同的速度增长并具有稍微不同的功能。功能的主要区别来自数据输入字段。差异基本上属于以下类别之一：

  1. 一个实例有几个字段，而另一个则没有。
  2. 字符串字段在一个实例中的最大长度为 200，但在另一个实例中为 50。
  3. 查找/参考字段具有不同的基础值（即相同的表结构，但来自不同的数据库）。
  4. 字段在一个实例中定义为用户提供的自由文本值，但在另一个实例中定义为查找/引用。

问题是公司内还有其他应用程序需要使用来自这三个独立应用程序的数据，但理想情况下，以核心/集中方式与它们通信（即通过中央服务而不是 3 个独立服务）。我的问题是如何处理，特别是上面的 D 项。我认为“最小公分母”方法可能是唯一的方法。例如：

<SomeFieldName>
  <Code></Code> <!-- would store a FK ref value if instance used lookup, otherwise would be empty or nonexistent-->
  <Text></Text> <!-- would store the text from the lookup if instance used lookup, would store user supplied text if not-->
</SomeFieldName>

关于此的其他想法/想法？

蒂亚！

4

2 回答 2

1

严格来说，数据模型视图的差异也是如此，或者应用程序级别是否存在功能性业务/行为差异。

如果是后者，那么我肯定会沿着您似乎正在使用 SOA 的道路前进。现在，您如何实现 SOA 仅取决于您的架构需求。我在设计中所关注的将是一些不同的模式。如果没有更多关于如何使用行为/功能差异的信息/示例，很难确定哪些（哪些）会满足需求。从我的脑海中，尽管你所描述的，我可能会开始在我的初始设计中查看策略模式。

使用 TDD 明确地对此进行原型制作，以便您可以确定您是否走在正确的道路上。

于 2009-06-11T16:53:47.607 回答
0

怎么样：扩展您的 LCD 方法，在这些系统前面放置一个外观。设计数据的规范化形式（如果填充了足够的数据）可以转换为任何特定实例。[前往这里的 ESB。]

那么问题来了，客户怎么知道“足够”是什么？可能需要某种元数据，以便您可以呈现合适的 UI。因此，扩展服务以提供交付元数据的操作。

于 2009-07-04T11:07:52.170 回答