Existe-t-il une bonne raison d’écrire du code dans Program.cs / main plutôt que d’utiliser des classes?

Il est difficile de le faire de cette façon, car la classe ne devient plus réutilisable / empaquetable dans une bibliothèque de classes sans avoir à manipuler la méthode principale.

Ce ne doit pas être comme ça.

Par exemple, chacun de vos scripts peut toujours avoir la même structure, mais également une méthode private static void Main(ssortingng[] args) . (Cela peut être non privé si vous voulez – tout dépend de vos besoins.)

De cette façon, il est autonome (peut être compilé comme une entrée unique pour une sortie unique puis exécuté) qui peut parfois être pratique, mais peut également être utilisé dans le cadre d’une bibliothèque de classes. La présence d’une méthode Main n’empêche en aucun cas l’utilisation de la classe à partir d’autres classes.

Il n’est pas clair si vous avez un fichier Program.cs ou un par script. Si vous en avez une par script, chacune de 4 à 5 lignes, cela semble un peu inutile.

Maintenant, ce ne serait certainement pas la façon dont je structurerais normalement une application volumineuse – mais si le but est d’avoir plusieurs “scripts” pouvant chacun être exécutés de manière autonome, donner à chaque classe une méthode Main ne semble pas trop grave.

En fait, ce que je fais souvent à des fins de démonstration consiste à avoir plusieurs classes avec des méthodes Main dans un seul projet, puis un point d’entrée séparé (qui se trouve dans Program.cs ), qui utilise la reflection pour rechercher toutes les autres et permet ensuite à l’utilisateur / présentateur pour choisir lequel exécuter.

Si tout votre code a du sens d’avoir une seule classe, alors avoir une petite méthode de saisie supplémentaire ne semble pas un tel problème. S’il s’agit en réalité de trop de code pour une seule classe, quel que soit le point d’entrée, le problème est différent. (Donc si vous tenez à avoir une seule ScriptClass alors ScriptClass réalité vous devriez donner différentes tâches à différentes classes, ce serait aussi mauvais.) De même, s’il insiste pour que tout le code soit dans une seule méthode , c’est certainement un problème pour les tests. et maintenabilité.

Je vous suggère de mettre de côté le désaccord relatif au point d’entrée pour le moment: trouvez la méthode la plus propre pour structurer tout le rest du code, et peu importe que la méthode Main utilisée dans Program.cs ou dans une autre classe.

Je pense que vous créez du travail pour vous-même, honnêtement. Je ne peux pas vous en dire plus dans les détails de votre description – mais si les scripts shell ont fonctionné, pourquoi le structurer là où la structure n’était apparemment pas nécessaire?

Vous dites que la modularité et le reconditionnement dans une bibliothèque externe sont quelque chose que vous devez faire – je voudrais contrer “pourquoi?” (c’est ce que je veux dire par travail supplémentaire).

Si vous créez un ensemble simple de méthodes dans un seul fichier, c’est un seul fichier! Par définition, il sera plus facile de travailler avec plusieurs projets, etc.

Cela dit – il est difficile de savoir de quoi on parle à moins d’avoir plus de détails. Si c’est “envoyer un rapport chaque soir et envoyer un courriel à ces personnes” – ouais c’est quelque chose qui n’a pas besoin d’une bibliothèque de classe et d’une tonne de modularité. Exécutez une méthode, vous avez terminé.

Vous savez que le point d’entrée d’une application console est configurable, n’est-ce pas?

Ma méthode préférée serait:

 class MeaningfullyNamedProgram { public static void Main(ssortingng[] args) { var program = new MeaningfullyNamedProgram(args); program.Run(); } public MeaningfullyNamedProgram(ssortingng[] args) { } public Run() { // well structured, broken-out code follows } } 

Pointez le point d’entrée du projet sur MeaningfullyNamedProgram.Main.

NOTE: Je le laisserai comme exercice pour le lecteur, mais vous pouvez créer une classe de base pour cela en utilisant des génériques et économiser de la dactylographie.

Votre responsable technique a besoin d’une bonne conversation! Tout mettre dans Program.cs n’est pas la voie à suivre.

Eh bien, sa façon de faire est conceptuellement plus simple, en ce sens que les programmes ont été écrits avant l’invention du sous-programme …

Votre méthode est meilleure: elle prend en charge la capacité de réutilisation et serait plus facile à modifier et à mettre au point.

La seule autre justification à laquelle je puisse penser pour son comportement était que s’il prenait beaucoup plus de temps pour le faire à votre façon que pour le faire à sa manière. Mais c’est un cas de reflection à court terme de sa part. Votre chemin résistera mieux à l’épreuve du temps.

Votre avance technique est fausse. La méthode que vous proposez est beaucoup plus raisonnable – elle permet de consolider facilement différents scripts. Chaque script ayant sa propre méthode Main peut devenir encombrant, en particulier si vous prévoyez de disposer d’une application pouvant en exécuter plusieurs à la fois.

Fractionner la logique en une ou plusieurs classes séparées est la voie à suivre. Tout mettre en un seul endroit viole les principes de conception SOLID et DRY. Vous êtes vraiment sur la bonne voie avec votre approche.

Plus vos cours sont concentrés sur des rôles uniques, plus votre vie sera facile pour la maintenance et les tests.

Si les fonctionnalités peuvent être utilisées autrement que par un programme console, vous devez bien sûr les conserver dans une bibliothèque de classes bien modélisée. Enregistrer quelques lignes de code en intégrant le traitement des parameters de ligne de commande à une fonctionnalité encapsulée n’a aucun sens, étant donné que les problèmes étaient à l’origine séparés. Peut-être que votre responsable technique devrait trouver des tâches plus productives pour vous, à mon humble avis.