服务设计（WCF、ASMX、SOA）

就一种模式或最佳实践征求反馈/想法，以解决多年来我见过几次的情况，但我还没有找到任何一种解决方案能够以我喜欢的方式解决这一问题

以下是背景

该公司有3个应用程序，支持3个相互关联的独立“业务线”。其中两个应用程序是从原始应用程序复制/粘贴的。应用程序需要能够以不同的速度增长，并且具有稍微不同的功能。功能上的主要差异来自数据输入字段。这些差异主要分为以下几类：

一个实例有几个字段 另一个没有

字符串字段的最大长度为200英寸 举个例子，但另一个例子是50

查找/引用字段已更改 不同的基础价值（即。 相同的表结构，但即将出现 来自不同的数据库）

字段定义为用户提供的字段， 自由文本，一个实例中的值， 而是在另一个数据库中查找/引用

问题在于，公司内还有其他应用程序需要使用这三个独立应用程序中的数据，但理想情况下，应以核心/集中的方式（即通过一个中央服务而不是三个独立的服务）与它们进行对话。我的问题是如何处理，特别是上面的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>

对此还有其他想法/想法吗

---

蒂亚

因此，这些差异与数据模型视图完全不同，或者在应用程序级别存在功能性业务/行为差异

如果是后一种情况，那么我将明确地沿着您似乎正在使用SOA的道路前进。现在，您如何实现SOA取决于您的体系结构需求。我将在设计中看到一些不同的模式。如果没有更多关于如何使用行为/功能差异的信息/示例，很难确定哪一个（或哪些）能满足需求。从我的头顶开始，根据你所描述的，我可能会开始在我最初的设计中寻找一种策略模式

---

使用TDD确定原型，这样你就可以确定你的方向是否正确。

如何：扩展你的LCD方法，在这些系统前面放一个门面。设计一种标准化的数据形式（若填充了足够的数据），可以将其转换为任何特定实例。[这里正朝着ESB前进。]

---

那么你就有问题了，客户如何知道什么是“足够”呢？可能需要某种元数据，以便您能够呈现一个可定制的UI。因此，扩展服务以提供传递元数据的操作。

每个应用程序的数据模型和行为都有变化，但现在，我试图解释模式/模型/数据契约的差异，而不是行为差异。问题是，对于哪些应用程序将要消耗我们的数据，我们没有硬性要求，只是对它们需要什么和过去的经验有一个大致的了解。我们正试图提出一种严格到足以定义我们的数据结构，但又足够宽松到允许差异和增长的东西。