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

Question

Я надеялся, что кто-то может помочь прояснить мои варианты относительно методов рефакторинга из программных кодов со страниц веб-форм ASP.NET.

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

То, что я изо всех сил пытаюсь завершить, - это разумный подход к удалению методов логики приложения изкод указывает, какой конкретный акцент делается на хранилище / DAL и как лучше структурировать классы BL.

Вот два варианта, которые я рассматриваю в настоящее время:

1.Создайте класс Business Logic дляИсходя из кода и из этого, предоставьте такие методы, как getProject(int id), которые могли бы закулисно получить доступ к экземпляру репозитория repo.GetById(int id)

Насколько я понимаю, преимущество этого будет следующим:

• отделить логику приложения от кодовых частей, позволяя им быть простыми
• , позволяястабильные методы в BLL (с ​​некоторыми изменениями), своего рода синонимичные с классами контроллеров в MVC (хотя это все еще веб-формы)
• Не предоставляет хранилище напрямую

Недостаткибудет:

• Множество методов-обёрток в BLL, которые на самом деле ничего не делают, кроме как скрывают методы репозитория

2.Пишите методы расширения на моих типах сущностейнапример, Project.getUsers(), который будет обращаться к методу экземпляра репозитория, позволяющему хранить BL без необходимости в конкретном классе BLL, тем самым уменьшая дублирование методов-оболочек в каждом классе BL.

Преимущество этого было бы:

• Нет необходимости иметь BL как таковой, сохраняя методы с их типом сущности
• Меньше методов-оболочек, так какНет необходимости в ProjectBL.getUsers(projectid) и UserBL.getUsers(projectid), которые оба вызывают repo.getProjectUsers(projectid) за кулисами, просто Project.getUsers() с обеих сторон кода

Недостаток этого, насколько я могу сказать:

• Если я буду вводить новые типы в будущем, например, 'SubProject' getUsers() необходимо повторно реализовать
• Я не слишком увлечен методами расширения в целом и неконечно, если это правильное место, чтобы использовать их!

Я немного не уверен, что это «лучшая» практика, или если я пропустил лучший вариант все вместе.Возможно, стоит знать, что изначально хранилище создавалось в коде и осуществлялось к нему напрямую, но, как я понимаю, это не идеально, поскольку мы рискуем вернуть такие вещи, как IQueryable, из хранилища и создать методы DAL, которыми можно манипулировать в кодепривести к противоречивым результатам.

Answer 1

Модель, которую я нашел наиболее эффективной в ASP.NET Webforms, - это шаблон bind / unbind. В этом паттерне единственные вещи, которые вы реализуете в самом коде, - это обработчики событий (которые будут вызывать более абстрактные, логически насыщенные методы в какой-либо BLL) и по одному методу каждый для передачи данных из (Bind) и в ( Unbind) экземпляр объекта домена или DTO.

Путем структурирования codebehind таким образом, класс codebehind начинает интересоваться только взаимодействием между логикой и представлением, и поэтому в большинстве случаев становится довольно тонким. Данные, с которыми он будет работать, будут в основном примитивами и DTO, и для этого не потребуются какие-либо знания DAL (по крайней мере, отдельные кодовые страницы не будут; вы можете настроить свою мастер-страницу или базовый класс для своих кодовых областей, чтобы иметь DAL-трогательные методы, общие для широких областей вашего сайта, в основном делая этот базовый класс вашим уровнем контроллера в коде).

Еще одна вещь, которую нужно иметь в виду, заключается в том, что в зависимости от структуры может быть очень просто выполнить модульное тестирование ваших классов кода. Вы можете даже TDD их, в точку; объявление базовых элементов GUI в разметке (и их объектных представлений в codebehind) по-прежнему лучше оставить в IDE, но общедоступный класс codebehind с общедоступными членами может быть легко создан в модульном тесте, а открытые методы реализованы .

Answer 2

@ KeithS Я собираюсь отметить это как принятое, поскольку никто, кажется, не имеет никаких предложений!Если вам любопытно, я предпочел больше использовать второй подход, в основном в моем приложении у меня есть несколько логических «разделов», таких как «Проекты» или «ApprovalForms», и я скорее создал отдельный класс BL на разделчем один в коде позади.

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