构建两个独立数据库集成的最佳方法? [英] Best approach to Architect the integration of two separate databases?
问题描述
我在工作中遇到了以下问题，但我没有经验或知识来回答这些问题，我希望你们中的一些聪明人能够为我指明正确的方向，任何答案将不胜感激！
I've ran into the following questions at work, and I don't have the experience or knowledge in order to answer them, I'm hoping that some of you wiser folk may be able to point me in the right direction, any answers will be greatly appreciated!
场景
我们的业务有两个方面使用单独的数据库，即人力资源和运营领域(家庭护理).
人力资源部跟踪公司的员工、轮班模式、缺勤、工资等. Homecare 跟踪客户信息、家访、访问日期以及负责提供访问的员工.
We have two aspects of the business using separate databases, Human resources and Operational Areas (Homecare).
Human Resources keep track of the company’s employees, shift patterns, absence, pay etc. Homecare keeps track of client information, home visits, visit dates and the employee/s responsible for providing that visit.
这两个系统是独立的，我们目前正在寻找整合它们的方法.
These two systems are separate and we’re currently in the process of looking at ways to integrate them.
此外，我们正在研究如何将查看这两个数据库的代码组织到可重用、有组织的库中.
Additionally, we’re looking at how to organise our code that looks at these two databases, into reusable, organised libraries.
我们有三个应用程序重用了 HumanResources.dll，负责与库中包含的 EF 4 对象上下文进行通信.对象上下文几乎是数据库的镜像.
We have three applications re-using a HumanResources.dll, responsible for communicating with an EF 4 object context, contained in the library. The object context is almost a mirror image of the database as it stands.
问题
我们即将添加第四个应用程序，该应用程序将使用 HR 数据库中的数据.
我们:
创建一个新的EF数据模型，负责提供信息只有应用程序需要，而复制一些常见的实体，例如作为员工.
Create a new EF data model, responsible for providing information that only the application needs, while duplicating some common entities such as the Employee.
OR
将新实体/表添加到已经很大的模型并接受它会变大.
Add the new entities/tables to the already large model and accept it’s going to get large.
<小时>
从长远来看，我们需要在第 5 个应用程序中将 HR 数据库中的轮班模式信息加入到运营区域(家庭护理)数据库的客户访问中.
我们已经有了可以做什么的想法；我们提出了以下建议:
We’ve got an idea on what we could do; we’ve come up with the following:
创建一个位于人力资源对象上下文和家庭护理对象上下文，负责用于连接两组数据一起.
Create a layer that sits between the HumanResources object context and Homecare object context, responsible for joining the two sets of data together.
还有其他方法可以使我们受益吗?
Are there any other approaches that would benefit us?
推荐答案
实施 Facade Pattern
外观基本上是复杂子系统的适配器.由于您有两个子系统，我建议您创建三个具有以下功能的类:
Implement the Facade Pattern
A facade is basically an adapter for a complex subsystem. Since you have two subsystems, I would recommend creating three classes with the following functionalities:
HumanResourcesFacade:包装所有人力资源"功能的类.此类的工作是公开执行人力资源应用程序负责的每个工作单元的方法，而不向客户公开有关人力资源应用程序的任何信息.
HumanResourcesFacade: A class that wraps all the "Human Resources" functionality. The job of this class is to expose methods that perform each Unit of Work that the Human Resources application is responsible for without exposing any information about the Human Resources application to the client.
HomecareFacade :包装所有家庭护理"功能的类.该类的工作是公开执行 Homecare 应用程序负责的每个工作单元的方法，而不向客户端公开有关 Homecare 数据库的任何信息.
HomecareFacade : A class that wraps all the "Homecare" functionality. The job of this class is to expose methods that perform each Unit of Work that the Homecare application is responsible for, without exposing any information about the Homecare database to the client.
ApplicationFacade :一个包含 HumanResourcesFacade 和 HomecareFacade 的类，并为您的客户提供不需要知识的公共方法两个嵌套立面之一的内部工作原理.该类的工作是知道:(a) 两个嵌套 Facade 中的哪一个负责每次客户端调用，(b) 通过调用嵌套 Facade 上的适当方法来执行客户端对 ApplicationFacade 的调用，以及(c) 将从嵌套 Facade 接收到的数据转换为客户端可用的格式，并且不依赖于任一嵌套 Facade 的数据格式.
ApplicationFacade : A class that wraps both HumanResourcesFacade and HomecareFacade and provides public methods to your clients that do not require knowledge of the inner workings of either of the two nested facades. The job of this class is to know: (a) which of the two nested facades are responsible for each client call, (b) execute the client's call of the ApplicationFacade by making a call to the appropriate method on the nested Facade, and (c) translating the data received from the nested facade into a format that is usable by the client and not dependent on the data formats of either nested facade.
我建议使用 POCO 对象模型来创建不依赖于实际持久性实现的数据的通用代码内表示.Adrian K 建议的领域模型技术是一种很好的方法，但如果您不熟悉模式和方法，最终可能会变得非常混乱，并且比更直观的技术花费的时间要长得多.另一种方法是仅使用数据对象和数据映射器.数据映射器，基本上是从数据源中获取数据并将其转换为不依赖于数据源或映射器对象的对象.我在下面包含了一个链接.
I would recommend using a POCO object model to create a common in-code representation of the data that is not dependent upon the actual persistence implementation. The domain model technique that Adrian K suggested is a good approach, but if you are not familiar with the patterns and methodology could end up being very confusing and taking much longer than techniques that are more intuitive. An alternative is to just use data objects and a Data Mapper. The data mapper, basically takes the data from a data source and turns it into an object that is not dependent on the data source or the mapper object. I included a link below.
我想澄清的一件事是，虽然我说 ApplicationFacade 有三项工作，但我并不是建议您违反 单一责任原则.我并不是说该类需要自己完成所有这三件事，而是它应该封装您决定用于执行该过程的任何机制，并且应用程序的其他部分不应从 <代码>ApplicationFacade.例如，您的业务对象不应该知道它们是从哪个数据源构建的 - 除了 ApplicationFacade 类封装的内容之外，不应从任何地方访问该信息.
One thing I would like to clarify is that while I said the ApplicationFacade has three jobs, I am not advising that you violate the Single Responsibility Principle. I do not mean that the class needs to do all those three things by itself, but that it should encapsulate whatever mechanism you decide to use for executing that process, and that no other parts of the application should access those concerns from outside of the ApplicationFacade. For example, your business objects should not know from which data source they were constructed - that information should not be accessible from anywhere other than what is encapsulated by the ApplicationFacade class.
这篇关于构建两个独立数据库集成的最佳方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
