服务设计（WCF，ASMX，SOA）

Question

征求关于解决一种情况的模式或最佳实践的反馈/想法，我在过去几年中看到过几次，但我没有找到任何一个解决方案能够像我希望的那样解决它。

以下是背景信息。

公司有三个应用程序，支持非常相关的三个“业务线”。其中两个应用程序与原始应用程序完全相同。这些应用程序需要能够以不同的速度增长并具有略微不同的功能。主要功能上的差异来自数据输入字段。这些差异基本上可以分为以下几类：

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>

你对此有其他想法/建议吗？

谢谢！

- Brian

Answer 1

那么这些差异严格来自数据模型视图，还是在应用程序层面存在功能业务/行为差异。

如果后者是情况，那么我肯定会走你似乎正在走的SOA路径。现在如何实施您的SOA取决于您的架构需求。我会考虑一些不同的模式进行设计。很难确定哪种模式可以满足需求，需要更多关于行为/功能差异如何使用的信息/示例。从我的经验中，根据您所描述的情况，我可能会从我的初始设计中开始查看策略模式。

一定要使用TDD进行原型设计，以便确定您是否正在走正确的道路。

- David Yancey

---

每个应用程序的数据模型和行为都有所不同，但目前，我正在尝试解决模式/模型/数据契约差异而不是行为差异的问题。问题在于，我们没有硬性要求哪些应用程序将使用我们的数据，只有一个大致的想法和过去的经验。我们正在努力设计一些严格定义我们数据结构的东西，同时又足够宽松以容纳差异和增长。 - Brian

Answer 2

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

然后您会遇到问题，客户端如何知道“足够”的含义？可能需要某种元数据，以便您可以提供适当的UI。因此，扩展服务以提供传递元数据的操作。

- djna