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

【问题标题】：is there a need to refactor a large data access layer是否需要重构大型数据访问层
【发布时间】：2010-12-29 17:04:37
【问题描述】：

我有一个数据访问层，它将应用程序的其余部分从持久性技术中抽象出来。现在的实现是 SQL 服务器，但这可能会改变。无论如何，随着我的表的增长（现在大约 40 个表），我发现这个主要的数据访问类变得越来越大。此数据访问层的接口是您可能想要获取数据的任何问题

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

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

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

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

【问题讨论】：

标签： sql data-access-layer single-responsibility-principle

【解决方案1】：

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

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

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

对存储过程的实际调用，包括日志记录和异常处理，可以而且应该进入一个单独的类。

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

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

我假设 - 记录 - 异常处理

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

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

【讨论】：

请不要“尝试 [..] 更改而不是添加新表”。很多表都不是问题。如果您需要一个，请创建一个。
我并不是在建议抛弃常识——请考虑以下两点：首先，为了数据模型的清晰度和性能，标准化的十字军东征可能是不好的。其次，我看到许多程序员为可以优雅地统一到单个数据结构（表）中的类型创建新表。

【解决方案4】：

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

【讨论】：