Quelle est la meilleure et de manière appropriée pour écrire le code dans Winforms?

Question

Quelle est la meilleure façon d'écrire le code?

(1) Comme écrit directement le code dans l'événement button_click().

ou

(2) Faire la fonction de ce code que je vous écris en cas de button_click() et d'écrire cette fonction dans une classe, puis cette fonction que je devrais appeler dans le button_Click() event.Like est-il appelé three-tier approach écrire le code?

Comme dans l'événement de button_Click() j'écrire le code pour sauvegarder les enregistrements dans csv file from datatable.So je devrais écrire ce code dans l'événement de button_Click() ou devrais-je faire une nouvelle fonction et une nouvelle classe et d'écrire ce code dans cette fonction qui est la nouvelle classe et d'appeler cette fonction en cas de button_Click().

Ceci est seulement un exemple, mais Je parle de tout le code écrit dans mon application ce qui est le appropriate and best way to write the code et quels sont les avantages? Notez que j'écris le code Winforms avec c #.

Answer 1

Vous devriez aller pour la fonction séparée dans une autre classe. Vous devriez faire cela parce que vous allez faire le code réutilisable et de créer une séparation entre l'interface correcte de l'utilisateur et la logique applicative. Comme cela, vous pouvez par exemple changer l'interface utilisateur sans affecter le reste de l'application.

Jetez aussi un coup d'œil à modèle MVC , vous comprendrez mieux l'idée.

La seule situation où je pense que la première option doit être utilisée est quand il fait une action qui aura une incidence sur l'interface utilisateur, et encore je vais créer cela dans une fonction séparée à l'intérieur de la classe Form.

Si cela affecte l'interface utilisateur, il devrait être dans la même classe, car il est lié et, par exemple si elle est un code pour rafraîchir une grille que je vais mettre cela dans une méthode distincte dans la même classe de formulaire, car cela pourrait être utilisé différents endroits à l'intérieur. Donc, changer l'interface utilisateur n'a pas d'incidence sur l'application, il vous suffit de rendre votre réutilisable et maintenable code.

Answer 2

Tout dépend de la situation.

Si vous allez faire des mises à jour du formulaire, il est préférable d'avoir le code de mise à jour dans le formulaire. Cependant, s'il y a beaucoup de traitement, alors sûrement il vaut mieux la conception d'avoir une poignée de classe séparée du travail.

Tout dépend de la situation.

Answer 3

En général, vous ne voulez pas logique dans le gestionnaire d'événements, puisque les interfaces graphiques ont tendance à fournir des mécanismes redondants (menu contextuel, la barre de menus, barre d'outils, touche d'accélérateur) pour déclencher la même commande, et les signatures d'événements ne sont pas compatibles pour toutes ces questions. Ensuite, la question est de savoir si votre fonction commune devrait aller dans la classe de formulaire ou dans le modèle de données.

Je commence souvent avec la logique dans la forme et refactoriser ensuite dans les classes du modèle au besoin. De nombreuses petites applications ne seront jamais assez grand pour que plusieurs classes sont nécessaires pour maintenabilité. Tant que vous évitez la duplication de code (à savoir copier + coller) puis refactorisation sera simple plus tard si vous vous trouvez besoin.

Answer 4

Il est toujours bon de développer des classes d'emplois. Comme il rend votre code réutilisable et mettre en œuvre également trois niveaux d'architecture. L'avantage est qu'il est facile à comprendre.
L'important est que, il est seulement bénéfique si vous développez vos classes de façon appropriée. Mettre au point des méthodes dans la classe qui peut être réutilisable pour vous.
L'autre avantage est qu'il cache la complexité de votre code.

Answer 5

Il existe deux approches générales de la structure en ajoutant au code: haut en bas et en bas. Haut vers le bas la structure vient du travail de conception qui peut impliquer un processus formel ou informel et des artefacts de conception pures comme des diagrammes UML ou les spécifications fonctionnelles. Le but ultime dans un processus descendant est de créer des classes et interfaces dans votre code qui fournira une structure appropriée pour rendre votre code maintenable. Cela peut se produire avant d'écrire le code, ou dans le cadre d'une itération, mais l'idée est que vous créez la structure, puis créer le code.

Structure de fond de haut vient de refactoring. Par exemple, commencez par toute votre logique dans un bouton clic. Lorsque vous ajoutez un élément de menu qui fait la même chose que le bouton clic, déplacez le code de votre bouton fonction de clic dans une fonction parlementaire sur le formulaire. Lorsque vous avez besoin des mêmes caractéristiques dans une autre partie de l'application, les variables de résumer le code et l'état utilisés par votre fonction parlementaire dans une classe.

Je vous recommande d'utiliser les deux approches. La bonne combinaison pour votre situation dépend de l'équipe de développement (taille, emplacement, capacité à communiquer) et la taille de votre application. D'une manière générale, les grandes applications nécessitent plus haut vers le bas, et sur des applications très petites une quantité minimale de haut en bas la conception est adéquate. Mais il devrait toujours y avoir une planification de haut niveau, même pour une petite application.