最好的办法，以建筑师两个单独的数据库的整合？ [英] Best approach to Architect the integration of two separate databases?

问题描述

我跑进在工作中以下问题，我没有为了回答这些问题的经验或知识，我希望你们中的一些聪明人或许可以点我在正确的方向，任何答案会大大AP preciated！

场景的

我们必须使用不同的数据库，人力资源和业务领域（家庭护理）业务的两个方面。结果
人力资源跟踪该公司的员工，轮班模式，不存在支付等家庭护理跟踪客户信息，家访，访问日期和员工/ S负责提供访问。

这两个系统是分开的，我们现在是在寻找方法将其整合的过程。

此外，我们正在考虑如何组织我们的code，着眼于这两个数据库，成可重用的，组织的图书馆。

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

问题的

---

的 我们将要添加将在人力资源数据库中使用数据的第四次申请。的

难道我们：

  

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

的或的

  

新的实体/表添加到
  已经较大的模型，并接受它的
  要得到大的。

---

从长远来看，我们需要加入的HR数据库的换档模式的信息在第5应用的业务领域的客户端访问（家庭护理）数据库。的

我们已经得到了什么，我们可以做一个想法;我们已经想出了以下内容：

  

创建了位于之间的一层
  HumanResources对象上下文和
  家庭护理对象上下文，负责
  用于接合所述两组数据
  在一起。

还有没有其他的办法，将有利于我们？

解决方案

实施外观模式

一个门面基本上是一个复杂的子系统的适配器。既然你有两个子系统，我会建议使用以下功能创建三类：

1. HumanResourcesFacade ：用于包装所有人力资源功能的类。这个类的工作是揭露执行每个工作单元的人力资源应用程序负责对方法没有关于人力资源应用到客户端的任何信息暴露。




2. HomecareFacade ：用于包装所有家庭护理功能的类。这个类的工作是揭露执行每个工作单元的家庭护理应用程序负责，而不对家庭护理数据库客户端的任何信息公开的方法。




3. ApplicationFacade ：一个包装类两种 HumanResourcesFacade 和 HomecareFacade 和提供公共方法给您的客户不需要的任何两个嵌套外墙的内部运作的知识。这个类的工作是了解：（a）在两个嵌套外墙有责任为每一个客户电话，（B）通过调用适当的方法对嵌套门面执行该applicationfacade的客户的电话，和（三）转换从嵌套门面接收到的格式是由客户端可用并且不依赖于任一嵌套门面的数据格式的数据。

我会建议使用POCO对象模型创建一个共同的IN-code再$ P $是不依赖于实际的持久化实现数据的psentation。阿德里安ķ提出的域模型技术是一种很好的方法，但是如果你不熟悉的模式和方法，最后都非常混乱，并采取更长的时间比那些更直观的技术。另一种方法是只使用数据对象和数据映射。数据映射器，基本上是从一个数据源获取数据并把它变成一个对象，它是不依赖于数据源或映射器对象上。我包括下面的链接。

有一件事我想澄清的是，虽然我说的是 ApplicationFacade 有三份工作，我不建议你违反的单一职责原则。我的意思不是说这个类需要由它自己做的所有这三样东西，但它应该封装你决定使用，用于执行过程中的任何机制，并且该应用程序的任何其他部分应该访问从外面这些问题 ApplicationFacade 。例如，您的业务对象应该不知道从哪个数据源，他们构建 - 信息不应该从比什么是由 ApplicationFacade 类封装任何地方的其他访问

参考文章

• Martin Fowler的应用上外立面


• Martin Fowler的上的数据映射器


• 一个免费的，但全面地介绍了领域驱动设计

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!

Scenario

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.

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.

Questions

---

We’re about to add a fourth application that will use data in the HR database.

Do we:

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.

---

Longer term, we need to join the Shift Pattern Information in the HR database to the Client Visits on the Operational Areas (Homecare) database in a 5th application.

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?

解决方案

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:

1. 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.

2. 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.

3. 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.

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.

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.

Reference Articles

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

这篇关于最好的办法，以建筑师两个单独的数据库的整合？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！