Какой самый лучший и подходящий способ написать код в Winforms?

Question

Как лучше всего написать код?

(1) Как и прямое написание кода в событии button_click().

или

(2) Создайте функцию из того кода, который я пишу в событии button_click(), и напишите эту функцию в одном классе, а затем эту функцию, которую я должен вызвать в событии button_Click(). Как будто она называется three-tier approach для записи код?

Как и в случае button_Click(), я пишу код для сохранения записей в csv file from datatable. Поэтому я должен написать этот код в событии button_Click() или создать одну новую функцию и один новый класс и написать этот код в этом функция, которая является новым классом и вызывающая эту функцию в событии button_Click().

Это только один пример, но Я говорю обо всем коде, написанном в моем приложении , что является appropriate and best way to write the code и каковы преимущества? Обратите внимание, что я пишу код в Winforms с помощью c #.

Answer 1

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

Также взгляните на шаблон MVC , вы лучше поймете всю идею.

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

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

Answer 2

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

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

Я бы рекомендовал использовать оба подхода. Правильное сочетание для вашей ситуации зависит от команды разработчиков (размер, местоположение, способность общаться) и размера вашего приложения. Вообще говоря, для больших приложений требуется больше сверху вниз, а для очень маленьких приложений достаточно минимального количества сверху вниз. Но всегда должно быть какое-то планирование высокого уровня, даже для небольшого приложения.

Answer 3

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

Answer 4

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

Я часто начинаю с логики в форме, а затем реорганизую ее в классы моделей по мере необходимости. Многие небольшие приложения никогда не станут настолько большими, что для удобства обслуживания потребуется несколько классов. Пока вы избегаете дублирования кода (т.е. копирование + вставка), рефакторинг будет проще, если вы обнаружите, что он вам нужен.

Answer 5

Все зависит от ситуации.

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

Все зависит от ситуации.