是否需要重构大数据访问层

Question

我有一个数据访问层，它将应用程序的其余部分从持久性技术中抽象出来。目前的实现是 SQL Server，但这可能会改变。不管怎样，我发现这个主要的数据访问类随着我的表的增长而变得越来越大（现在大约有 40 个表）。此数据访问层的接口是您可能想要获取有关其

 public interface IOrderRepository
 {
       Customer[] GetCustomerForOrder(int orderID);
       Order[] GetCustomerOrders(int customerID);
       Product[] GetProductList(int orderID);
       Order[] GetallCustomersOrders(int customerID);
       etc . . .
 }

背后实现的数据的任何问题，这是运行适当查询并在类型化集合中返回结果的基本 SQL 存储过程，

这将不断增长。它非常易于维护，因为没有真正的单一责任中断，但该类现在有超过 2000 行代码。

所以问题是，由于确定的类大小（并且没有真正的概念耦合），这是否应该被分解，如果是的话，在什么维度或抽象级别上。

Answer 1

绝对重构。 2000行是巨大的。

我首先按返回类型将其分解。因此，您将获得一类用于访问产品、一类用于访问订单、一类用于访问客户等等。

对于每个类，选择的列集可能应该相同，以便在将 SQL 值提取到对象中时可以将其重构为单个变量/方法。

此外，对存储过程的实际调用（包括日志记录和异常处理）可以而且应该放入单独的类中。

顺便说一句，你确实违反了单一责任。根据您的描述，您的类现在具有以下职责：

• 创建用于查询表的 sql 语句（大约 40 次）
• 水合存储过程的调用结果
• 调用存储过程

我假设
- 日志记录
- 异常处理

Answer 2

我认为应该仅仅因为尺寸而考虑它。总是有很多维度可以分解。由于细分只是为了使代码更易于管理，因此不要选择太复杂的维度 - 保持简单，以便很容易猜测给定函数将在哪个类/接口中找到。

Answer 3

这是一个很难破解的问题....首先将其分解为多个文件和类，其次将业务对象与技术对象分离；您可以根据数据库接口（您自己编写）来编写业务对象。将来如果您更改数据库，您只需更换技术对象即可。

遗憾的是，您无法真正摆脱数据模式的增长，您将获得更多的存储过程、更多的表和更多的业务对象。但是，请尽量尝试更改而不是添加新表。

我建议尝试形成一个将项目作为资源耦合在一起的工作流程。我的意思是不创建物理依赖项，而是创建文档，让您将数据层中的所有三种类型的项目关联起来——例如，您可以开始在业务对象的注释中添加注释来指定哪些存储过程和表这取决于。您甚至可以对 SQL Server 中的表中的存储过程执行此操作（架构具有表的描述字段）。这些提示应该可以帮助您了解全局。

Answer 4

如果您的语言可以容纳通用 DAO，请考虑使用通用 DAO。您还可以考虑通过示例进行查询以减少所需的调用次数。