数据所有权和性能

Question

我们正在设计一个新的应用程序，在考虑数据所有权时遇到了一些架构问题。

我们将系统分解为组件，例如客户和订单。每个组件/模块负责特定的业务域，即客户处理客户的CRUD和以客户为中心的业务流程（注册新客户，阻止客户帐户等）。每个模块都是一组数据库表的所有者，只有该模块可以访问它们。如果另一个模块需要另一个模块拥有的数据，它会通过从该模块请求它来检索它。

到目前为止，问题是如何处理诸如需要向所有客户和每个客户展示所有订单的报告等情景？在这种情况下，我们需要从Customer模块获取所有客户，迭代它们，并为每个客户获取Order模块中的所有数据。性能不会很好......显然，拥有存储过程加入客户表和订单表会好得多，但这也意味着直接访问另一个模块所拥有的数据，创建我们的耦合和依赖关系希望避免。

这是一个简化的示例，我们正在处理具有大量业务实体和关系的企业应用程序，我的目标是保持其清洁和尽可能松散耦合。我预计将来会对数据方案进行许多更改，并可能将系统拆分为几个完全独立的系统。我希望有一种设计可以让它以相对简单的方式完成。

Answer 1

我认为这是存储库模式的一个很好的例子，您可以在其中定义包含所有数据逻辑的接口（或少数接口）。然后，通过IoC将此接口的实现传递给组件。

虽然这种模式不能完全解决耦合问题，但报告存储库可以了解客户表，但至少知识将包含在少数类中。 （理论上你可以将报告逻辑放在客户存储库中，但这不是最好的做法，因为用户比报告更“原始”，但它取决于系统，并且意味着更少的耦合）

您可以获得有关存储库模式here和here

的更多信息

Answer 2

您可以针对不同级别的解决方案拥有不同的所有者（或所有权理念）。

根据物理架构应用数据的所有权是有意义的（尽管并非总是如此）。

一旦达到业务逻辑级别，您可能会拥有全新的“所有者”和范围 - 这些将拥有他们正在显示的“视图”（数据片段），而不是所拥有的各个数据位它了。我认为这完全没问题。

即使在存储过程级别，这也没关系。仅仅因为拥有某些东西并不意味着它可以共享。

Answer 3

我会在这里建议两种方法之一

• 使用您的示例，如果您正在构建具有报告需求的企业系统，则应考虑将报告实现与代码分离，并利用报告框架从数据存储中提取数据并进行呈现。您将有意识地决定绕过您的业务领域图层
• 第二个建议是创建一个新的表示域层，它将为您的系统提供只读数据，在这种情况下，它可以专门针对单个报告需求获取/准备非规范化数据或DTO。提供此数据的后端数据层可以是您在编程环境中可用的存储过程或其他机制（例如.NET中的LINQ），它将为您提供所需的性能。由于表示层仅提供只读操作和对象，因此您的所有事务操作仍需要遍历业务域层。

Answer 4

您有2个一般形式的对象责任 - CRUD＆amp;只读。 客户和订单模块拥有各自的数据（表格，权利等）并偶尔与他人共享。

我只想选择最快，最有效的所有权形式 - 不要求报告模块向您的标准商业模块索取任何内容。您的业​​务模块将承担其他责任。报告需要尽可能使用存储过程作为独立模块运行，并具有自己的规则，访问权限等。

Answer 5

我对同一个问题采用了不同的方法：每个模块都有自己的接口，对吗？在这种情况下，通过接口你的意思是一个编程接口，如EJB接口（在java中），或.h文件（在旧的普通C中）等...但是如果你有一个数据库（即使每个模块）拥有一组表，你可能拥有一个单独的数据库）你可以将你的界面的某些部分暴露为数据库中的一个视图。在这种情况下，每个模块将定义一组程序接口和一组“DB接口”，仅用于查询目的。您将能够使用简单的SQL和连接读取报表的数据，并且只能访问模块要公开的内容。