logo标签列表

最佳方法来设计整合两个独立数据库的架构？

database-designarchitectureentity-framework-4integrationfacade
8
我在工作中遇到了以下问题，但是我没有经验或知识来回答它们，希望你们中的一些更聪明的人可以指引我正确的方向，任何答案都将不胜感激！
场景
我们的业务有两个方面使用单独的数据库，人力资源和操作区域（家庭护理）。 人力资源跟踪公司员工、班次、缺勤、工资等信息。家庭护理跟踪客户信息、上门拜访、拜访日期以及提供该服务的员工/员工组。
这两个系统是分开的，我们目前正在寻找集成它们的方法。 此外，我们正在研究如何组织查看这两个数据库的代码，以便重复使用并且是有组织的库。
我们有三个应用程序重复使用HumanResources.dll，负责与包含在库中的EF 4对象上下文进行通信。对象上下文几乎是现有数据库的镜像。
问题
我们即将添加第四个应用程序，该应用程序将使用HR数据库中的数据。
我们应该：
创建一个新的EF数据模型，负责提供只有应用程序需要的信息，同时复制一些常见的实体，例如员工。
还是
将新实体/表添加到已有的大型模型中，并接受它将变得更大。
长期来看，我们需要在第五个应用程序中将HR数据库中的班次信息与操作区域（家庭护理）数据库中的客户访问相关联。
我们有一个想法;我们想到了以下方法：
创建一个层，位于HumanResources对象上下文和Homecare对象上下文之间，负责将这两组数据连接在一起。
还有其他方法可以使我们受益吗？
这似乎是LDAP的工作。 - Flavius
4个回答
12

实现Facade模式

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

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

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

  3. ApplicationFacade：包装HumanResourcesFacade和HomecareFacade并为客户端提供公共方法，这些方法不需要了解任何嵌套外观的内部工作原理。该类的作用是知道：(a)哪个嵌套外观负责每个客户端调用，(b)通过对嵌套外观的适当方法进行调用来执行应用程序外观的客户端调用，以及(c)将从嵌套外观接收到的数据转换为客户端可用且不依赖于任何嵌套外观数据格式的格式。

我建议使用POCO对象模型来创建一个通用的代码内数据表示，该表示不依赖于实际的持久化实现。Adrian K建议的领域模型技术是一个好的方法，但如果你不熟悉这些模式和方法，可能会变得非常混乱，比更直观的技术花费更多的时间。另一种选择是只使用数据对象和数据映射器(Data Mapper)。数据映射器基本上从数据源中获取数据，并将其转换为不依赖于数据源或映射器对象的对象。我在下面包含了一个链接。
我想澄清的一件事是，虽然我说ApplicationFacade有三个职责，但我并不建议您违反单一职责原则。我的意思不是这个类必须自己做所有这三件事情，而是它应该封装您决定用于执行该过程的任何机制，并且应用程序的其他部分不应该从ApplicationFacade之外访问这些问题。例如，您的业务对象不应该知道它们是从哪个数据源构建的-除了由ApplicationFacade类封装的信息之外，其他地方都不应该访问这些信息。
参考文章
在编程中，使用外观模式来抽象持久化和参考DDD书籍上的InfoQ。 - orangepips
+1、悬赏和答案，非常感谢您为这个答案付出的时间！它对我帮助很大！ - Zack
2
听起来你需要进行一些严肃的数据建模。
长期而言，你绝对需要这样做，这样你才不会陷入严重的麻烦。(如果有一件事情会对你支持/扩展系统以及支持业务增长产生重大影响，那就是数据管理)。(商业)数据的好处是，你的业务利益相关者将会（或应该）对其有良好的了解，并适当地积极支持你。这样一项练习所带来的价值应该是很容易的销售点。在短期内实施其中一部分也会有所帮助。
带有产品包装的数据源（商业现成品-COTS）将无法更改，否则将使这些系统面临风险，但这并不意味着你不能使用ETL和其他数据库来创建将不同数据结合在一起的数据集市。在这种方法中，数据建模和系统之间的数据映射将非常重要，而且时间安排也很重要。
你在内部应用程序中会拥有更多的灵活性，但除非你有非常充分的理由，否则你可能不想进行战术性的变更，否则你很可能仍然需要重新制定它们。
作为这个练习的一部分，您需要考虑每个数据片段的记录系统——它来自哪里？谁拥有它？您可以从高层次开始制定概念性数据模型，这可能更多地涉及逻辑数据集而不是具体的“列”。
使用这些信息来指导进一步的决策。
就您的直接方法（以及您的问题）而言：一般而言，我会考虑在系统和数据之间放置一层抽象层，以便当发生更改时应用程序免受影响。
使用一个新的EF数据模型，负责提供应用程序所需的信息，同时复制一些常见实体，如员工。
重复使用的大问题在于将数据变得混乱，这是“真实”记录。这很容易让人崩溃。在您的背景下，这种方法的好处是什么？您是否出于可支持性或开发便利性而这样做？
你好Adrian，感谢您的回复。我们面临的问题是我们的业务有两个方面运行在不同的数据库上。每个方面都有各种各样的应用程序，我们无法承担重写的成本。我们正在寻找一种方法，在未来的项目中使用Entity Framework 4和C#集成这两个数据库，而不是从头开始。 - Zack
所以我想绘制数据流和数据映射图可以帮助您管理该集成。我想您要集成的是“数据”，而不是实际的物理数据库；这是一个微妙的区别，人们并不总是看得到。 - Adrian K
啊，没错。我们无法重新设计数据库，因为有太多的应用程序使用每一个数据库，修改或重写它们不是一个选项。我们正在寻找一种整合数据的方法。 - Zack
这可以比你提出的方案少做很多工作就能完成。 - steinberg
是的，这是一个好方法；我想我是从较低级别的数据库中心化视角出发的 :) - Adrian K
显示剩余3条评论
1

这很大程度上取决于您所说的“集成”是什么意思。

  • 如果您只想为报告目的合并各种表格，则应查看一些过程，从每个系统中提取和加载选定的数据到数据仓库中。您需要为两个系统定义一个共同的数据模型。然后可以使用此数据进行报告。
  • 如果您希望一个系统调用另一个系统的服务或检索数据，则建议您使用经典的SOA模式。通过SOAP、REST消息或类似方式将要公开的功能作为服务公开。并让客户端系统使用这些方法，并且仅使用这些方法来发送或检索数据。

尽可能避免直接查看外部系统数据库，复制数据从一个系统到另一个系统，或直接调用源系统的API。

+1，对于Web服务建议以及指导原则。 - smartcaveman
0

既然您正在寻找长期解决方案，而且涉及到企业基础设施，我建议您迁移到LDAP。请仔细阅读。

你能详细说明一下如何使用LDAP来解决这个具体问题吗？ - smartcaveman
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接