Question

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.

Answer 1

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:

• create sql statements for querying a table (about 40 times)
• hydrating the results of calls to stored procedures
• calling stored procedures

And I am assuming
– logging
– exception handling