database-design - 构建两个独立数据库集成的最佳方法？

Question

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

场景

我们的业务有两个方面使用独立的数据库:人力资源和运营领域(家庭护理)。
人力资源部门跟踪公司的员工、轮类模式、缺勤、工资等。家庭护理部门跟踪客户信息、家访、访问日期以及负责提供该访问的员工。

这两个系统是独立的，我们目前正在寻找将它们集成的方法。

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

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

问题

<小时/>

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

我们是否:

Create a new EF data model, responsible for providing information that only the application needs, while duplicating some common entities such as the Employee.

或者

Add the new entities/tables to the already large model and accept it’s going to get large.

<小时/>

从长远来看，我们需要将人力资源数据库中的轮类模式信息加入到第五个应用程序中运营领域(家庭护理)数据库的客户访问中。

我们已经知道可以做什么；我们提出了以下方案:

Create a layer that sits between the HumanResources object context and Homecare object context, responsible for joining the two sets of data together.

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

Answer 1

实现Facade Pattern

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

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

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

3. ApplicationFacade :一个包装 HumanResourcesFacade 和 HomecareFacade 的类，并向您的客户端提供公共(public)方法，这些方法不需要了解两个嵌套外观的内部工作原理。此类的工作是了解:(a) 两个嵌套 Facade 中的哪一个负责每个客户端调用，(b) 通过调用嵌套 Facade 上的适当方法来执行客户端对 ApplicationFacade 的调用，以及( c) 将从嵌套外观接收的数据转换为客户端可用的格式，并且不依赖于任一嵌套外观的数据格式。

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

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

引用文章

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