Есть ли у кого-нибудь советы по сохранению логики из моих классов графического интерфейса? Я стараюсь использовать хороший дизайн класса и держать как можно более раздельным, но мои классы формы обычно заканчиваются тем, что смешивается с не-UI, чем я хотел бы, и это, как правило, делает обслуживание настоящей болью.Разделение пользовательского интерфейса и логики на C#
(Visual Studio 2008 Professional, C#, приложения для Windows).
Большое спасибо.
Поместите свою логику в отдельную сборку; и постройте эту сборку без ссылки на какие-либо GUI-пакеты (например, System.Drawing, System.Windows.Forms и т. д.).
Вы должны смотреть на шаблоны проектирования, такие как:
Model-View-Controller (MVC) часто используемых веб-сайтов (ASP.NET)
Model-View-View Model (MVVM) часто используемых WPF
Сохраняя одному из вы должны уметь разделить различные части вашего приложения.
Есть другие модели, которые выполняют аналогичную работу.
Кроме того, разработка с помощью WPF может помочь, поскольку пользовательский интерфейс определяется XAML и кодом, который делает работу C#. Это может обеспечить базовую степень разделения. Если вы обнаружите, что пишете код C#, который просто управляет пользовательским интерфейсом, вы можете сделать шаг назад и подумать: «Должен ли я делать это в XAML?». Очевидно, что в коде есть вещи, которые вам нужно сделать, но это начало.
3-слойная архитектура - это то, что вы ищете.
Вы строите 2 многоразовые слоев:
Тогда на вашем проекте UI ссылайтесь на многоразовые слои и обрабатывайте только специфические элементы интерфейса. В рамках проекта UI переговоры только к УСК, не имеющие прямого подключения к DAL:
< UI ---> BLL < ---> DAL
Вы можете иметь несколько слоев UI, потребляющие ваши повторно используемые компоненты, а также множественные взаимозаменяемые DAL, если вы хотите поддерживать несколько типов баз данных.
Это действительно вопрос практики и самодисциплины. Я имею в виду, мы все это сделали. И мы все продолжаем это время от времени при неправильных условиях (менеджер/клиент кричит, чтобы что-то сделать «прямо сейчас» против «права» и т. Д.).
Одна вещь, которую я делаю при написании кода для управления пользовательским интерфейсом (больше на веб-странице, но то же самое относится) - спрашивать себя с каждой единицей кода (одна строка, условный, цикл и т. Д.).) зависит ли этот фрагмент кода от наличия пользовательского интерфейса. Если я пишу в текстовое поле, это зависит от пользовательского интерфейса, поэтому оно идет туда. Но если я рассчитываю результат, который пойдет в это текстовое поле, это, вероятно, бизнес-логика.
Другой подход (как ChrisW, намеченный во время ввода) заключается в том, чтобы сначала разработать логику в библиотеке классов, отличных от UI. Положите столько логики, сколько сможете (используйте свое суждение относительно того, что определяет «логику»), которая не зависит от библиотек на основе UI. Затем создайте пользовательский интерфейс, чтобы использовать эту логику. Существуют разные подходы к параллельной разработке этих двух частей, такие как завершение логической сборки за классами интерфейсов и просто кодирование фрагментов пользовательского интерфейса для этих интерфейсов (затем использование инъекции зависимостей для подключения классов сборки к интерфейсам) и т. Д.
Обычно в таких ситуациях; Я создаю класс вспомогательного метода, который выполняет весь тяжелый подъем.
Что касается поддержания логики отдельно; определить ключевые компоненты и реорганизовать их в класс вспомогательного метода. Например; если я обрабатываю GridView для обновления записей на основе того, выбраны они или нет; и если они есть, обновите ShipDate в форме; Сначала я выясню, выбрана ли строка; затем извлеките поле Id, затем ShipDate, а затем передайте Id и ShipDate в метод моего вспомогательного класса, который выполняет всю работу.
Единичные тесты могут быть вашими друзьями здесь; в основном, если у вас есть какой-либо код, который использует тип «логического типа»; он должен иметь единичный тест. Если он находится в классах GUI; это трудно проверить; однако как только вы реорганизовываете его; единичный тест должен быть тривиальным.
Вы должны смотреть на следующих моделей:
MVC (Model-View-Controller) MVVM (Model-View-View-модель) - В основном используется в WPF с его богатой поддержка привязки данных. MVP (Model-View-Presenter) - часто используется для WinForms и веб-приложений (из-за представления без состояния)
Отметьте это сообщение в блоге, в котором приводится пример использования MVP для просмотра веб-страниц и WinForms с одной ведущий: http://www.cerquit.com/blogs/post/MVP-Part-I-e28093-Building-it-from-Scratch.aspx
Кроме того, еще один блог здесь описывается с помощью шаблона MVP для модульного тестирования бизнес-логики: http://www.cerquit.com/blogs/post/Model-View-Presenter-Part-II---Unit-Testing.aspx
Узнайте, как писать классы контроллеров, которые могут быть DataBound к форме и как выполнить привязку данных. В WinForms это в основном сводится к интерфейсам INotifyPropertyChanged и IDataErrorInfo в классе контроллера и с использованием экземпляров BindingSource в классе формы.
Тогда вы можете написать класс контроллера, который содержит ВСЕ данные и логику для пользовательского интерфейса, а класс интерфейса просто связывается с ним. Тогда ваш пользовательский интерфейс становится очень тонким, и ваша логика пользовательского интерфейса (удерживаемая в контроллере) становится очень проверкой (модульные тесты сложны при работе с классами пользовательского интерфейса, но гораздо проще при работе с классами контроллеров).
Это основа всех конструкций MVC/MVVM.
Херби
Одним словом, это называется Рефакторинг.
Есть только несколько причин, чтобы поставить код в UI:
Все остальные код «бизнес-логики» переходит в другой класс называется бизнес-логики класса. Весь код взаимодействия с базой данных входит в другой класс, называемый классом доступа к данным.
Когда вы пишете код в пользовательском интерфейсе, просто спросите себя, взаимодействует ли код с элементом управления в форме. Если нет, он, вероятно, принадлежит к двум другим классам.
Ознакомьтесь с некоторыми книгами Мартина Фаулера по рефакторингу, например «Рефакторинг: улучшение дизайна существующего кода». Еще одно звуковое слово - это разделение проблем. Я знаю, что вы можете сделать все это в одном классе, но код становится намного читабельнее и легче отлаживается, когда он разделяется на классы, как я описал выше.
Спасибо - я думаю, что это хорошая практическая отправная точка, чтобы помочь мне правильно подумать. – Andy