есть ли необходимость в рефакторинге большого уровня доступа к данным - PullRequest
Новая
       16

есть ли необходимость в рефакторинге большого уровня доступа к данным

3 голосов
/ 24 декабря 2009

У меня есть уровень доступа к данным, который абстрагирует остальную часть приложения от технологии персистентности. Прямо сейчас реализация является сервером 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 ]

2 голосов
/ 24 декабря 2009

Абсолютно рефакторинг. 2000 строк огромны.

Я бы начал с разбивки по типу возвращаемого значения. Таким образом, вы получите один класс для доступа к Продуктам, один для заказов, один для клиентов и т. Д.

Для каждого класса выбранный набор столбцов, вероятно, должен быть одинаковым, чтобы его можно было реорганизовать в одну переменную / метод при извлечении значений SQL в объекты.

Кроме того, фактический вызов хранимой процедуры, включая ведение журнала и обработку исключений, может и должен идти в отдельный класс.

Кстати, у вас есть нарушение единоличной ответственности. Согласно вашему описанию ваш класс сейчас имеет следующие обязанности:

  • создать SQL-операторы для запроса таблицы (около 40 раз)
  • увлажнение результатов обращений к хранимым процедурам
  • вызов хранимых процедур

И я предполагаю, - протоколирование - обработка исключений

1 голос
/ 24 декабря 2009

Это сложная проблема для взлома .... во-первых, разбейте ее на несколько файлов и классов, а во-вторых, отделите бизнес-объекты от технологического объекта; Вы можете написать свои бизнес-объекты с точки зрения интерфейса базы данных (который вы пишете сами). и затем в будущем, если вы измените БД, все, что вам нужно, это заменить технологический объект.

К сожалению, вы действительно не можете избежать роста схемы данных, вы получите больше хранимых процедур, больше таблиц и больше бизнес-объектов. Однако лучше постарайтесь изменить свой уровень, а не добавлять новые таблицы.

Я предлагаю попытаться сформировать рабочий процесс, соединяющий их вместе в качестве ресурсов. Под этим я подразумеваю не создание физических зависимостей, а документацию, которая позволит вам связать все три типа элементов на вашем уровне данных - например, вы можете начать добавлять аннотации в комментарии ваших бизнес-объектов, чтобы указать, какие хранимые процедуры и таблицы это зависит от. Вы можете сделать это для хранимых процедур даже в таблицах в SQL Server (схема имеет поле описания для таблиц). Эти советы помогут вам следить за общей картиной.

1 голос
/ 24 декабря 2009

Я думаю, что это должно быть учтено только из-за размера. Всегда есть много измерений, в которых вы можете разбить его. Поскольку разбивка состоит просто в том, чтобы сделать код более управляемым, не выбирайте слишком сложное измерение - сделайте его простым, чтобы было легко догадаться, в каком классе / интерфейсе будет найдена данная функция.

0 голосов
/ 24 декабря 2009

Рассмотрим общий DAO, если ваш язык соответствует им. Вы также можете подумать о запросе на примере, чтобы сократить количество требуемых вызовов.

...