是否需要重构大数据访问层
我有一个数据访问层，它将应用程序的其余部分从持久性技术中抽象出来。目前的实现是 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 行代码。
所以问题是，由于确定的类大小（并且没有真正的概念耦合），这是否应该被分解，如果是的话，在什么维度或抽象级别上。
i have a data access layer that abstracts the rest of the application away from the persistence technology. Right now the implementation is SQL server but that might change. Anyway, i find this main data access class getting larger and large as my tables grow (about 40 tables now). The interface of this data access layer is any question you might want to get data on
public interface IOrderRepository
{
Customer[] GetCustomerForOrder(int orderID);
Order[] GetCustomerOrders(int customerID);
Product[] GetProductList(int orderID);
Order[] GetallCustomersOrders(int customerID);
etc . . .
}
the implementation behind this is basic SQL stored procs running the appropriate queries and returning the results in typed collections
this will keep growing and growing. Its pretty maintainable as there isn't a real break of single responsibility but the class is now over 2000 lines of code.
so the question is, due to sure class size (and no real conceptual coupling), should this get broken down and if so on what dimension or level of abstraction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
绝对重构。 2000行是巨大的。
我首先按返回类型将其分解。因此，您将获得一类用于访问产品、一类用于访问订单、一类用于访问客户等等。
对于每个类，选择的列集可能应该相同，以便在将 SQL 值提取到对象中时可以将其重构为单个变量/方法。
此外，对存储过程的实际调用（包括日志记录和异常处理）可以而且应该放入单独的类中。
顺便说一句，你确实违反了单一责任。根据您的描述，您的类现在具有以下职责：
我假设
- 日志记录
- 异常处理
Absolutely refactor. 2000 lines is huge.
I'd start by breaking it down by return type. Thus you would get one class for accessing Products, one for Orders, one for Customers and so on.
For each of the class, the set of columns selected should probably the same, so that could get refactored into a single variable/method as the extracting of the SQL values into objects.
Also the actual call to the Stored Procedure, including logging and exception handling could and should go into a separate class.
BTW you do have a violation of single responsibility. According to your description your class right now has the following responsibilities:
And I am assuming
- logging
- exception handling
我认为应该仅仅因为尺寸而考虑它。总是有很多维度可以分解。由于细分只是为了使代码更易于管理，因此不要选择太复杂的维度 - 保持简单，以便很容易猜测给定函数将在哪个类/接口中找到。
I think it should be factored just because of the size. There are always lots of dimension on which you can break it down. Since the breakdown is simply to make the code more manageable, don't choose too complex a dimension - keep it simple so that it is easy to guess in which class/interface a given function will be found.
这是一个很难破解的问题....首先将其分解为多个文件和类，其次将业务对象与技术对象分离；您可以根据数据库接口（您自己编写）来编写业务对象。将来如果您更改数据库，您只需更换技术对象即可。
遗憾的是，您无法真正摆脱数据模式的增长，您将获得更多的存储过程、更多的表和更多的业务对象。但是，请尽量尝试更改而不是添加新表。
我建议尝试形成一个将项目作为资源耦合在一起的工作流程。我的意思是不创建物理依赖项，而是创建文档，让您将数据层中的所有三种类型的项目关联起来——例如，您可以开始在业务对象的注释中添加注释来指定哪些存储过程和表这取决于。您甚至可以对 SQL Server 中的表中的存储过程执行此操作（架构具有表的描述字段）。这些提示应该可以帮助您了解全局。
This is a hard problem to crack .... firstly break it into multiple files and classes, and secondly split the business objects from the technology object; you can write your business objects in terms of a database interface (which you write yourself). and then in the future if you change DB all you need is to replace the technology object.
Sadly You can't really escape from data-schema growth, you will get more stored-procedures, more tables and more business objects. However, try your level headed best to alter rather than add new tables.
I suggest trying to form a workflow of coupling items them together as resources. By this I mean not making physical dependencies but documentation that will let you relate all the three types of items in you data layer -- e.g.., you could start putting annotations in the comments of your business objects to specify which stored-procedures and tables it depends on. You could do this for the stored-procedures even in the tables in SQL Server (the schema has a description field for tables). These tips should help you keep sight of the big-picture.
如果您的语言可以容纳通用 DAO，请考虑使用通用 DAO。您还可以考虑通过示例进行查询以减少所需的调用次数。
Consider a generic DAO if your language accomodates them. You might also think about query by example to cut down on the number of calls required.