8

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

设想

我们使用单独的数据库来处理业务的两个方面，即人力资源和运营领域（家庭护理）。
人力资源跟踪公司的员工、轮班模式、缺勤、工资等。家庭护理跟踪客户信息、家访、访问日期和负责提供访问的员工。

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

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

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

问题

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

我们要不要：

创建一个新的 EF 数据模型，负责提供只有应用程序需要的信息，同时复制一些常见的实体，例如 Employee。

或者

将新实体/表添加到已经很大的模型中并接受它会变大。

从长远来看，我们需要在第 5 个应用程序中将 HR 数据库中的轮班模式信息加入到操作区域（家庭护理）数据库的客户访问中。

我们已经知道我们可以做什么；我们提出了以下建议：

创建一个位于 HumanResources 对象上下文和 Homecare 对象上下文之间的层，负责将两组数据连接在一起。

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

4

4 回答 4

12

实现外观模式

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

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

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

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

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

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

参考文章

于 2011-03-05T16:41:52.877 回答
2

听起来你需要做一些严肃的数据建模。

从长远来看，您肯定需要它，以免陷入严重的冲突。（如果有一件事会对您支持/扩展系统和支持业务增长的能力产生重大影响——那就是数据管理）。（业务）数据的好处是您的业务利益相关者将（或应该）对它有很好的理解，并有适当的动力支持您。这种做法将带来的价值应该很容易卖出。在短期内实施其中的一些措施也会有所帮助。

软件包产品（商业现货 - COTS）附带的数据源不会在不将这些系统置于风险的情况下进行更改 - 但这并不意味着您不能使用 ETL 和其他数据库来创建带来不同的数据集市数据在一起。在这种方法中，数据建模和系统之间的数据映射将很重要——但时机也很重要。

您将拥有更多的内部应用程序灵活性 - 但您可能想要抵制战术变化，除非您有非常令人信服的理由，否则您可能不得不重新设计它们。

作为本练习的一部分，您需要考虑每条数据的记录系统——它来自哪里？谁拥有它？您可以通过绘制概念数据模型从高级开始，这可能会处理更多的逻辑数据集而不是特定的“列”。

使用此信息来指导进一步的决策。

就您的直接方法（和您的问题）而言：一般而言，它会考虑在您的系统和数据之间放置一个抽象层，以便在发生这种情况时缓冲应用程序的变化。

创建一个新的 EF 数据模型，负责提供只有应用程序需要的信息，同时复制一些常见的实体，例如 Employee。

重复的最大问题是让数据进入一种浑浊的状态——这是“真正的”记录。这很容易杀死你。在您的情况下，这种方法有什么好处？从可支持性的角度来看，您会这样做吗？易于开发？

于 2011-02-24T12:20:30.423 回答
1

这在很大程度上取决于您所说的集成。

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

尽可能避免直接查看外部系统数据库，将数据从一个系统复制到另一个系统，或直接调用源系统的 API。指导原则应该是“如果我用系统 SuperX 替换系统 X，那么保持其他系统正常工作有多容易”。

于 2011-06-15T05:17:04.387 回答
0

由于您正在寻找一个长期的解决方案，而且它与业务的基础设施有关，我建议您迁移到LDAP。读一读。

于 2011-06-16T07:35:22.557 回答