Как структурировать приложения Windows Forms на VB.NET

У меня был большой успех с этим шаблоном Пассивный экран.

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

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

Уловка для решения этой проблемы заключается в создании сборки контроллера, на которую ссылается сборка формы (или EXE). Каждая форма имеет соответствующий класс в сборке. Нажатие кнопки вызовет ThisForm.ThisButton(<args>), который затем активирует объекты ниже в вашей структуре. Каждая форма реализует интерфейс, поэтому, если классу контроллера требуется дополнительная информация из формы, у него есть интерфейс для ее извлечения.

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

Есть важное исключение, и это касается тривиальных диалогов. Для диалогов, в которых есть несколько флажков, я считаю, что такая организация излишня. Я много использую шаблон команды. Итак, в сборке, где я определяю объекты Command, я помещаю ПРОСТОЙ диалог, связанный с этой командой. Насколько простым должен быть диалог, чтобы получить такое лечение, зависит от вас.

Мне нравится структурировать свои приложения следующим образом.

• Утилита - это сборка, в которой есть вещи, которые я использую постоянно - математические функции, файловые функции и т. д.

• Объекты - это конкретные объекты, которые я использую для этого приложения.

• UIFramework - определяет все интерфейсы форм и контроллеров.

• Команды - здесь есть все объекты Command, которые управляют объектами моего приложения.

• UI - объекты, реализующие интерфейсы контроллера

• EXE - формы, реализующие интерфейс формы и вызывающие объекты контроллера.

Вы можете попробовать популярный CSLA Framework Рокки Лхотки. Он обеспечивает очень структурированный способ реализации бизнес-объектов, поэтому вы можете не допускать использования кода, не относящегося к пользовательскому интерфейсу, в ваших формах. Помимо простого разделения бизнес-логики, он обеспечивает встроенную отмену n-уровня, проверку, безопасность, поддержку привязки данных и т. д.

Одна жалоба, которая чаще всего направляется в адрес CSLA, заключается в том, что он затрудняет разработку, основанную на тестировании, так что это тоже может быть предметом рассмотрения.

Что-то, что может очень помочь, - это использование Пользовательские элементы управления. С пользовательскими элементами управления вы можете повторно использовать один и тот же пользовательский интерфейс в разных формах. Кроме того, у вас может быть много пользовательских элементов управления в одной форме, поэтому, если у вас есть форма с элементом управления вкладками, имеющая 5 вкладок, содержимое каждой вкладки может быть пользовательским элементом управления, поэтому вместо того, чтобы сотни элементов управления были смешаны в одной форме , каждый пользовательский элемент управления имеет свои собственные элементы управления и логику проверки, и в итоге вы получаете всего шесть элементов управления в форме: tabcontrol и 5 пользовательских элементов управления.

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