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

Question

Каков наилучший способ структурировать приложение VB.NET Windows Forms , чтобы можно было повторно использовать код и легко расширять приложение?

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

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

Расширенные формы наследуют и расширяют этот базовый класс форм.

1. В этой области уже проделана работа?
2. Есть ли в наличии книги / статьи, в которых обсуждаются варианты, доступные по этой теме?

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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