Quels sont les inconvénients de l'utilisation de méthodes statiques dans une couche de gestion de site Web par rapport à l'instanciation d'une classe et à l'appel d'une méthode sur la classe? Quels sont les résultats obtenus dans les deux cas?Quels sont les inconvénients des méthodes statiques?
Les différences de performance seront négligeables. L'inconvénient de l'utilisation d'une méthode statique est qu'elle devient moins testable. Lorsque les dépendances sont exprimées dans les appels de méthodes statiques, vous ne pouvez pas remplacer ces dépendances par des mock/stubs. Si toutes les dépendances sont exprimées en interfaces, où l'implémentation est transmise au composant, vous pouvez utiliser une version simulée/stub du composant pour les tests unitaires, puis l'implémentation réelle (éventuellement associée à un conteneur IoC) pour le réel. déploiement.
Si la méthode utilise des données statiques, celles-ci seront partagées par tous les utilisateurs de votre application Web. Code seulement, pas de vrais problèmes au-delà des problèmes habituels avec les méthodes statiques dans tous les systèmes.
Jon Skeet est juste - la différence de performance serait insignifiant ...
Cela dit, si vous construisez une application d'entreprise, je suggère d'utiliser l'approche traditionnelle adoptée par plusieurs niveaux Microsoft et un certain nombre de d'autres sociétés de logiciels. Permettez-moi d'expliquer brièvement:
Je vais utiliser ASP.NET parce que je le connais très bien, mais cela devrait facilement se traduire par n'importe quelle autre technologie que vous utilisez.
La couche de présentation de votre application comprendrait des pages ASP.NET aspx pour l'affichage et des codes-behind ASP.NET pour le "contrôle de processus". C'est une façon élégante de parler de ce qui se passe quand je clique sur soumettre. Est-ce que je vais à une autre page? Y at-il une validation? Dois-je enregistrer des informations dans la base de données? Où vais-je après ça?
Le contrôle de processus est la liaison entre la couche de présentation et la couche de gestion. Cette couche est divisée en deux parties (et c'est là que votre question entre). La manière la plus flexible de construire cette couche est d'avoir un ensemble de classes de logique métier (par exemple, PaymentProcessing, CustomerManagement, etc.) qui ont des méthodes telles que ProcessPayment, DeleteCustomer, CreateAccount, etc. Ce sont des méthodes statiques. Lorsque les méthodes ci-dessus sont appelées à partir de la couche de contrôle de processus, elles traitent toute l'instanciation d'objets métier (par exemple, client, facture, paiement, etc.) et appliquent les règles métier appropriées.
Vos objets métier géreront toutes les interactions de la base de données avec votre couche de données. Autrement dit, ils savent comment sauvegarder les données qu'ils contiennent ... c'est similaire au modèle MVC.
Alors - quel est l'avantage de cela? Eh bien, vous avez toujours la testabilité à plusieurs niveaux. Vous pouvez tester votre interface utilisateur, tester le processus métier (en appelant les classes de logique métier avec les données appropriées) et tester les objets métier (en les instanciant manuellement et en testant leurs méthodes.) Vous savez également que si votre modèle de données ou les objets changent, votre interface utilisateur ne sera pas affectée, et seulement vos classes de logique métier devront changer.En outre, si la logique métier change, vous pouvez modifier ces classes sans affecter les objets
Espérons que cela aide un peu
Pour des raisons de performances, l'utilisation de méthodes statiques évite le surdébit de la création/destruction d'objet, ce qui est généralement non significatif.
Elles ne doivent être utilisées que lorsque l'action prise par la méthode n'est pas liée à l'état, par exemple, pour les méthodes d'usine. Cela n'aurait aucun sens de créer une instance d'objet juste pour instancier une autre instance d'objet :-)
String.Format(), les méthodes TryParse() et Parse() sont toutes de bons exemples lorsqu'une méthode statique a du sens . Ils exécutent toujours la même chose, n'ont pas besoin d'état et sont assez communs, donc l'instanciation a moins de sens. D'un autre côté, les utiliser quand cela n'a pas de sens (par exemple, devoir passer tout l'état dans la méthode, disons, avec 10 arguments), rend tout plus compliqué, moins facile à maintenir, moins lisible et moins testable comme Jon dit. Je pense que ce n'est pas pertinent s'il s'agit d'une couche de gestion ou n'importe où ailleurs dans le code, utilisez-les seulement avec parcimonie et lorsque la situation le justifie.
"Il ne serait pas logique de créer une instance d'objet juste pour instancier une autre instance d'objet :-)" - cela fonctionne si vous devez dire à quelqu'un comment créer des instances d'un certain type d'une manière simulable/connectable. C'est le modèle d'usine. –
Je parle du modèle de méthode d'usine là ... –
Cela dépend. La classe statique System.Math ne semble pas moins testable qu'elle ne l'aurait été si elle n'était pas statique. Est-ce que je me trompe, Jon? –
Ce n'est pas que la méthode statique elle-même ne soit pas testable - c'est que les choses utilisant des méthodes statiques ne sont pas testables, parce que vous ne pouvez pas remplacer l'implémentation de la méthode statique par une méthode simple. Par exemple, si la méthode frappe la base de données, votre test le sera également. –