3

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

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

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

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

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

4

4 回答 4

2

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

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

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

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

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

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

我假设 - 记录 - 异常处理

于 2009-12-24T03:47:01.020 回答
1

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

于 2009-12-24T03:03:20.407 回答
1

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

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

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

于 2009-12-24T03:06:22.140 回答
0

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

于 2009-12-24T03:07:28.737 回答