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

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

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

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

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

Проделана ли уже работа в этой области?
Существуют ли книги/статьи, в которых обсуждаются варианты, доступные по этой теме?

Ответ 1

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

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

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

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

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

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

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

Утилита - это сборка, в которой есть все, что я использую все время - математические функции, файловая функция и т.д.
Объекты. У этого объекта есть конкретные объекты, которые я использую для этого приложения.
UIFramework - определяет все формы и интерфейсы контроллера.
Команды. У этого объекта есть все объекты Command, которые управляют моими объектами приложения.
UI - объекты, реализующие интерфейсы контроллера
EXE - формы, которые реализуют интерфейс формы и вызывают объекты контроллера.

Ответ 2

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

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

Ответ 3

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

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