构建两个独立数据库集成的最佳方法？
我在工作中遇到了以下问题，我没有经验或知识来回答这些问题，我希望你们中的一些明智的人能够为我指明正确的方向，任何答案将不胜感激！
场景
我们的业务有两个方面使用单独的数据库：人力资源和运营领域（家庭护理）。
人力资源部跟踪公司的员工、轮班模式、缺勤、工资等。家庭护理部跟踪客户信息、家访、访问日期以及负责提供访问的员工。
这两个系统是独立的，我们目前正在寻找将它们集成的方法。
此外，我们正在研究如何将查看这两个数据库的代码组织成可重用的、有组织的库。
我们有三个应用程序重复使用 HumanResources.dll，负责与库中包含的 EF 4 对象上下文进行通信。对象上下文几乎是数据库的镜像。
问题
我们即将添加第四个应用程序，该应用程序将使用 HR 数据库中的数据。
我们是否：
创建一个新的 EF 数据模型， 负责提供信息 只有应用程序需要，而 复制一些常见的实体，例如 作为员工。
或者
将新实体/表添加到 已经很大的模型并接受它 会变得很大。
从长远来看，我们需要将人力资源数据库中的轮班模式信息加入到第 5 个应用程序中运营领域（家庭护理）数据库的客户访问中。
关于我们可以做什么的想法；我们提出了以下方案：
创建一个位于 HumanResources 对象上下文和 Homecare 对象上下文，负责 用于连接两组数据 一起。
还有其他方法可以使我们受益吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
实现外观模式
外观基本上是复杂子系统的适配器。由于您有两个子系统，我建议创建三个具有以下功能的类：
HumanResourcesFacade：包装所有“人力资源”功能的类。此类的工作是公开执行人力资源应用程序负责的每个工作单元的方法，而不向客户端公开有关人力资源应用程序的任何信息。HomecareFacade：包装所有“Homecare”功能的类。此类的工作是公开执行 Homecare 应用程序负责的每个工作单元的方法，而不向客户端公开有关 Homecare 数据库的任何信息。ApplicationFacade：一个包装HumanResourcesFacade和HomecareFacade的类，并向您的客户端提供不需要了解内部工作原理的公共方法两个嵌套立面中的任何一个的。此类的工作是了解：(a) 两个嵌套 Facade 中的哪一个负责每个客户端调用，(b) 通过调用嵌套 Facade 上的适当方法来执行客户端对 ApplicationFacade 的调用，以及（ c) 将从嵌套外观接收的数据转换为客户端可用的格式，并且不依赖于任一嵌套外观的数据格式。我建议使用 POCO 对象模型来创建不依赖于实际持久性实现的通用数据代码表示。 Adrian K 建议的领域模型技术是一种很好的方法，但如果您不熟悉模式和方法，最终可能会变得非常混乱，并且比更直观的技术花费更长的时间。另一种方法是仅使用数据对象和数据映射器。数据映射器基本上从数据源获取数据并将其转换为不依赖于数据源或映射器对象的对象。我在下面添加了一个链接。
我想澄清的一件事是，虽然我说
ApplicationFacade有三项工作，但我并不建议您违反 单一职责原则。我的意思并不是说该类需要自己完成所有这三件事，而是它应该封装您决定用于执行该过程的任何机制，并且应用程序的任何其他部分都不应从 < 外部访问这些问题代码>ApplicationFacade。例如，您的业务对象不应该知道它们是从哪个数据源构建的 - 除了ApplicationFacade类封装的内容之外，该信息不应该从任何地方访问。参考文章
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: 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: 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: A class that wraps bothHumanResourcesFacadeandHomecareFacadeand 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
ApplicationFacadehas 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 theApplicationFacade. 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 theApplicationFacadeclass.Reference Articles
听起来您需要进行一些认真的数据建模。
从长远来看，你肯定需要它，这样你就不会陷入严重的冲突。 （如果说有一件事会对您支持/扩展系统和支持业务增长的能力产生重大影响，那就是数据管理）。 （业务）数据的好处是您的业务利益相关者将（或应该）对其有很好的理解，并有适当的动力来支持您。这种做法所带来的价值应该是很容易推销的。在短期内落实其中一些措施也会有所帮助。
软件包产品（商业现成的 - COTS）附带的数据源不会开放更改，否则这些系统将面临风险 - 但这并不意味着您不能使用 ETL 和其他数据库来创建数据集市，从而带来不同的数据集市。数据在一起。在这种方法中，数据建模和系统之间的数据映射非常重要，而且时机也很重要。
您将在内部应用程序方面拥有更大的灵活性 - 但您可能希望抵制战术变化，除非您有非常令人信服的理由，否则您可能不得不重新设计它们。
作为本练习的一部分，您需要考虑每条数据的记录系统 -它从哪里来？谁拥有它？您可以通过制定概念数据模型从高层开始，这可能更多地处理逻辑数据集而不是特定的“列”。
使用此信息来指导进一步的决策。
就您的直接方法（以及您的问题）而言：一般来说，它会考虑在系统和数据之间放置一个抽象层，以便在发生变化时应用程序免受变化的影响。
重复的一个大问题是让数据进入一种混乱的状态——这是“真实的”记录。这很容易杀死你。在您的环境中，这种方法有什么好处？您会从支持性的角度这样做吗？开发方便吗？
Sounds like you need to do some serious data-modeling.
You definitely need it for the long term so that you don't get yourself into serious strife. (if there's one thing that will have a significant impact on your ability to support / extend systems and support business growth - it's data management). The good thing about (business) data is that your business stakeholders will (or should) have a good understanding of it and be suitably motivated to support you. The value such an exercise will bring should be an easy sell. Having some of this in place in the short term will help as well.
Data sources which come with packages products (Commercial Off The Shelf - COTS) will not be open to change without putting those systems at risk - but that doesn't mean you can't use ETL and other databases to create data marts that bring disparate data together. In this sort of an approach the data modeling, and data mapping between systems will be important - but also the timing.
You will have more flexibility with in-house apps - but you might want to resist tactical changes unless you have a very compelling reason, otherwise you'll probably have to re-work them anyway.
As part of this exercise you'll want to consider the System of Record of each piece of data - where does it come from? Who owns it? You can start at a high-level by drawing up a conceptual data model, this will probably deal more with logical datasets than specific "columns".
Use this information to guide further decisions.
In terms of your immediate approach (and your question): in general terms it'd think about putting a layer of abstraction between your systems and the data, so that the applications are cushioned from change when that happens.
The big issue with duplication is getting the data into a state thats muddy - which is the "real" record. This can easily kill you. What are the benefits of this approach in your context? Would you be doing this from a supportability perspective? Ease of development?
这在很大程度上取决于您所说的集成的含义。
如果可能的话，请避免直接查看外部系统数据库、将数据从一个系统复制到另一个系统，或者直接对源系统进行 API 调用。
指导原则应该是“如果我用 SuperX 系统替换 X 系统，那么保持其他系统正常运行将是多么容易”。
It depends very much on what you mean by integration.
Avoid if at all possible looking directly into the foreign systems database, replicating data from one system to the other, or making direct API calls to the source system.
The guiding principle should be "if I replace system X with system SuperX how easy would it be to keep the other systems working".
由于您正在寻找长期解决方案，并且涉及业务基础设施，因此我建议您迁移到 LDAP。读一读。
Since you are looking for a long-term solution, and it's about business' infrastructure, I recommend you will migrate to LDAP. Have a read.