Question

我有一个数据访问层，它将应用程序的其余部分从持久性技术中抽象出来。现在，实现是SQL服务器，但可能会改变。无论如何，我发现随着我的表的增长，这个主数据访问类变得越来越大（现在大约有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。您也可以考虑通过示例查询来减少所需的调用次数。

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

4 个答案: