Как избежать дублирования логики на двух одинаковых WinForms?
У меня две формы: форма A и форма B. Эти формы должны отличаться по внешнему виду, но в них много логики. Проблема в том, что эта логика привязана к внешнему виду (проверка при нажатии кнопки, запускаемых событиях и т. д.). Например, у меня есть поле имени, и при нажатии кнопки сохранения мне нужно запустить событие, которое заставляет родительскую форму проверять имя записи, чтобы избежать дублирования. Обе формы нуждаются в этой логике, но их кнопки сохранения находятся в разных местах, и всплывающая подсказка, которая отображается при возникновении ошибки, также должна отображаться в другом месте. Это всего лишь один пример, но знает ли кто-нибудь способ избежать копирования и вставки кода сюда? Возможно, я упускаю что-то очевидное ...
Ответы 5
Вы можете создать объект с данными, представленными в обеих формах, и поместить в этот объект логику проверки. Уровень представления должен заполнить этот объект введенными данными, попросить объект проверить себя, а затем обработать ошибки проверки в зависимости от формы.
Если общая логика связана с пользовательским интерфейсом, вам необходимо создать свой собственный класс настраиваемой формы (который наследуется от класса формы) с желаемой логикой. тогда все, что вам нужно сделать, это унаследовать этот класс в ваших формах.
Если общая логика меньше связана с пользовательским интерфейсом, создайте внутренний класс, который инкапсулирует общую логику, и вызовите его из обеих форм.
Вам нужно добавить Контроллер между вашими двумя представлениями и вашей общей моделью. Таким образом, вам просто нужно будет сделать: myController.save (); вместо этого вам нужно вызвать объект модели, чтобы сохранить их в обоих winform.
Спасибо, но я не думаю, что реализация логики типа MVC в этом одном случае была бы очень практичной на данном этапе.
Что ж, это случай гибкости -> Усилия. (с минимальными усилиями) Вы можете просто использовать общий код в статических методах, иметь объект, совместно используемый формами, и, наконец (гибкость ++), вместо этого объект, который ВЛАДЕТ ВЛАДЕНИЕМ с формами (Контроллер).
Что ж, принятый ответ - это именно то, что я написал 1 час назад: наличие «контроллера», который сохраняет, действителен и все другие необходимые вам вещи, которых не должно быть в представлении (WinForm). Я не могу достаточно объяснить ...
Это. По правде говоря, хотя я знаю основы MVC, я никогда не использовал его формально. Я все равно ставил вам +1 за помощь.
Я могу придумать несколько способов рефакторинга этих форм для совместной работы с логикой. Вы можете использовать один или несколько из них вместе:
- Создавайте специфичные для пользовательского интерфейса «bean-объекты», которые обертывают ваш бизнес-объект и добавляют дополнительные функциональные возможности, общие для форм. Этот bean-компонент может делать такие вещи, как создавать подсказки по инструментам, помогать с проверкой, обработкой событий и т. д.
- Создайте вспомогательный класс с общими функциями. Обобщите логику двух форм, чтобы вызвать этот вспомогательный класс для общих функций.
- Улучшите свои бизнес-объекты для проверки. Я не хочу сказать, что ваши БО должны знать какой-либо пользовательский интерфейс, но они могут / должны обеспечивать соблюдение бизнес-правил. Это может перенести часть логики проверки из ваших форм в общее место.
- Создавайте настраиваемые элементы управления, соответствующие типу данных, с которыми вы работаете, и используйте эти элементы управления в двух формах.
Вы также можете взглянуть на CSLA Framework, я довольно успешно использовал его в прошлых проектах, чтобы уменьшить количество дублированного кода между различными пользовательскими интерфейсами. Он использует возможности привязки данных .NET, но я не думаю, что необходимо использовать привязку данных только для того, чтобы получить максимальную отдачу от фреймворка.
Хотя это правильный ответ, я не думаю, что он очень полезен для OP, учитывая этот вопрос. Некоторые ссылки на MVC, MVP и реализацию с использованием WinForms, вероятно, будут очень полезны.