Делаем устаревший и понятный код приложения win.forms более понятным

Question

У меня есть старое приложение win.forms, написанное с довольно простым подходом, где формы взаимодействуют с DAL в событиях пользовательского интерфейса.Например, есть текстовые поля: логин / пароль, кнопка - «Логин» и обработчик кликов, где реализована бизнес-логика (DAL запрашивается, чтобы получить пользователя по идентификатору / паролю, если не ноль - чем показывать следующий экран, если ноль - показывать«Повторить экран»).

У меня нет возможности переписать его с нуля (в MVP или шаблоне View / Document), я просто хочу отделить бизнес-логику от обработчиков: захватить существующий код обработчиков, взаимодействующих с DAL, и сгруппировать его где-нибудь из пользовательского интерфейсаобработчики.

Десятки форм состоят из десятков пользовательских элементов управления, и зачастую неясно, кто отвечает за бизнес-логику.Иногда это контроль пользовательского интерфейса.Но иногда это форма, которая слушает пользовательское событие управления пользовательским интерфейсом и затем реализует бизнес-логику.

Если я разделяю бизнес-логику, кто должен отвечать за вызов контроллеров бизнес-логики?Формы, пользовательские элементы управления или формы и пользовательские элементы управления одновременно?

Заранее спасибо!

Answer 1

Как и в большинстве случаев рефакторинга, делайте небольшие шаги.

Начните с извлечения кода в новый метод. Поэтому вместо всего кода входа в событие btnLogin_Click у вас будет просто метод с именем LogUserIn () или что-то в этом духе.

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

Затем вы можете начать использовать этот класс в ваших обработчиках событий. Что-то вроде UserData.Login (имя, pw) и UserData.Logout (имя)

Не пытайтесь делать все сразу. Внесите изменение, убедитесь, что оно работает, внесите другое изменение, убедитесь, что оно работает до тошноты.

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

Answer 2

Мое субъективное мнение было бы разделить столько, сколько вы можете.Вставьте весь код бизнес-объекта в собственную библиотеку или класс, поместите все поведение, относящееся к вашим бизнес-объектам, в этот класс.Затем разрешите вызывать код вашего пользовательского интерфейса. Если вам нужно подождать между обменом данными (например, поиск в огромной базе данных учетных данных для входа), остановите пользовательский интерфейс, пока он не услышит ответ от ваших бизнес-объектов.Преимущества этого подхода в том, что вы можете теоретически распространять его в будущем ... имея сервер, на котором выполняется внутренний код, и пользовательский интерфейс просто отправляет запросы и ожидает ответов.Хотя, возможно, я неправильно понял ваш вопрос?