架构两个独立数据库的最佳方法？

Question

我在工作中遇到了以下问题，我没有经验或知识来回答这些问题，我希望你们中的一些人可以指出我正确的方向，任何答案将不胜感激！

情景

我们有两个方面的业务使用单独的数据库，人力资源和业务领域（家庭护理） 人力资源部门跟踪公司的员工，轮班模式，缺勤，薪酬等.Homecare会跟踪客户信息，家访，访问日期以及负责提供访问的员工。

这两个系统是分开的，我们目前正在研究如何整合它们。

此外，我们正在研究如何将查看这两个数据库的代码组织成可重用，有组织的库。

我们有三个应用程序重新使用HumanResources.dll，负责与库中包含的EF 4对象上下文进行通信。对象上下文几乎是数据库的镜像。

问题

---

我们即将添加第四个将在HR数据库中使用数据的应用程序。

我们：

  

创建一个新的EF数据模型，   负责提供信息   只有应用程序需要，而   复制一些常见的实体   作为员工。

或

  

将新实体/表添加到   已经很大的模型并接受它   会变大。

---

从长远来看，我们需要将人力资源数据库中的班次模式信息加入第5个应用程序中操作区域（家庭护理）数据库的客户访问。 < / p>

我们已经了解了我们能做些什么;我们提出以下建议：

  

创建一个位于。之间的图层   HumanResources对象上下文和   家庭护理对象的背景，负责任   用于加入两组数据   在一起。

还有其他方法可以使我们受益吗？

Answer 1

实施Facade Pattern

Facade基本上是复杂子系统的适配器。由于您有两个子系统，我建议创建三个具有以下功能的类：

1. HumanResourcesFacade：包含所有“人力资源”功能的类。此类的工作是公开执行人力资源应用程序负责的每个工作单元的方法，而不向客户公开任何有关人力资源应用程序的信息。

2. HomecareFacade：包含所有“Homecare”功能的课程。本课程的工作是公开执行Homecare应用程序负责的每个工作单元的方法，而不向客户公开有关Homecare数据库的任何信息。

3. ApplicationFacade：包含HumanResourcesFacade和HomecareFacade的类，并为您的客户提供公共方法，这些方法不需要知道两个嵌套中任何一个的内部工作方式门面。这个类的工作是知道：（a）两个嵌套外观中的哪一个负责每个客户端调用，（b）通过调用嵌套Facade上的适当方法来执行客户端对ApplicationFacade的调用，并且（ c）将从嵌套外观接收的数据转换为客户端可用的格式，而不依赖于嵌套外观的数据格式。

我建议使用POCO对象模型来创建不依赖于实际持久性实现的数据的公共代码表示。 Adrian K建议的领域模型技术是一种很好的方法，但是如果你不熟悉模式和方法，最终可能会比非常直观的技术更加混乱和花费更长的时间。另一种方法是使用数据对象和数据映射器。数据映射器基本上从数据源获取数据并将其转换为不依赖于数据源或映射器对象的对象。我在下面添加了一个链接。

我想澄清的一点是，虽然我说ApplicationFacade有三份工作，但我并不是说你违反了Single Responsibility Principle。我并不是说该类本身需要完成所有这三件事，而是它应该封装您决定用于执行该过程的任何机制，并且应用程序的其他任何部分都不应该从{的外部访问这些关注点。 {1}}。例如，您的业务对象不应该知道它们是从哪个数据源构造的 - 除了ApplicationFacade类封装的内容之外的任何地方都不应该访问该信息。

参考文章

• Martin Fowler on Application Facades
• Martin Fowler on Data Mappers
• A free, but thorough introduction to Domain Driven Design

Answer 2

听起来你需要做一些严肃的数据建模。

你肯定需要长期使用它，这样你就不会陷入严重的冲突。 （如果有一件事会对您支持/扩展系统和支持业务增长的能力产生重大影响 - 那就是数据管理）。关于（业务）数据的好处是，您的业务利益相关者将（或应该）对其有一个很好的理解，并有适当的动力来支持您。这样的练习带来的价值应该是一个容易出售。在短期内实现一些这些也将有所帮助。

包装产品附带的数据源（商业现货 - COTS）如果不将这些系统置于危险之中，将无法改变 - 但这并不意味着您不能使用ETL和其他数据库来创建数据集市将不同的数据放在一起。在这种方法中，数据建模和系统之间的数据映射将是重要的 - 但也是时间。

您可以更灵活地使用内部应用程序 - 但除非您有非常令人信服的理由，否则您可能希望抵制战术变化，否则您可能无论如何都要重新进行操作。

作为本练习的一部分，您需要考虑每个数据的System of Record - 它来自哪里？谁拥有它？您可以通过绘制概念数据模型从高级别开始，这可能会更多地处理逻辑数据集而不是特定的“列”。

使用此信息指导进一步的决策。

就你的直接方法（以及你的问题）而言：一般来说，它会考虑在你的系统和数据之间放置一层抽象，以便在发生这种情况时缓解应用程序的变化。

  

    

创建一个新的EF数据模型，负责提供只有应用程序需要的信息，同时复制一些常见实体，例如Employee。

  

重复的一个大问题是将数据变成一个混乱的状态 - 这是“真正的”记录。这很容易杀死你。在您的上下文中，此方法有哪些好处？你会从支持性的角度来做这件事吗？易于开发？

Answer 3

这在很大程度上取决于你的整合意味着什么。

• 如果您只想将各种表组合起来进行报告，那么您应该查看一些流程，以便将每个系统中的选定数据提取并加载到Datawarehouse中。您需要为两个系统定义通用数据模型。然后可以将这些数据用于报告。
• 如果您希望一个系统调用服务或从另一个系统检索数据，那么我建议您使用经典的SOA模式。通过SOAP，REST消息或类似方法将您想要提供的功能公开为其他系统作为服务。并让客户端系统使用这些方法，只使用这些方法来发送或检索数据。

尽可能避免直接查看外部系统数据库，将数据从一个系统复制到另一个系统，或者直接对源系统进行API调用。 指导原则应该是“如果我用系统SuperX替换系统X，那么保持其他系统工作是多么容易”。

Answer 4

由于您正在寻找长期解决方案，而且它是关于业务的基础架构，因此我建议您迁移到LDAP。读一读。