Couches statiques dans une application Web Java

Question

Je construis un petit site Web pour le plaisir et l’apprentissage en utilisant une conception en couches Web / Service / Data Access relativement standard.

Pour éviter de devoir créer en permanence des instances de mes classes de couche de couche service / couche d'accès aux données, j'ai rendu toutes les méthodes statiques. Je ne devrais pas avoir de problèmes de concurrence car ils utilisent des variables locales, etc. et ne partagent aucune ressource (les choses sont assez simples pour cela pour le moment).

Pour autant que je sache, le seul inconvénient est que je ne suis pas une vraie approche OO, mais que le code reste beaucoup plus propre.

Y a-t-il une raison pour que cette approche ne soit pas viable? Quel genre de problèmes pourrait survenir plus tard? Serait-il préférable d'avoir une "usine"? classe pouvant me renvoyer des instances des classes de services et de couches de données selon les besoins?

Answer 1

Inconvénients:

• Vous ne pourrez pas écrire de tests unitaires, ni d'écrire des objets de logique fictive d'accès aux données / de logique métier à tester.
• Vous aurez des problèmes de simultanéité lorsque différents threads essaieront d'accéder au code statique en même temps - ou si vous utilisez des méthodes statiques synchronisées, vous vous retrouverez avec des threads en file d'attente pour utiliser les méthodes statiques.
• Vous ne pourrez pas utiliser de variables d'instance, ce qui deviendra une restriction à mesure que le code devient plus complexe.
• Il sera plus difficile de remplacer des éléments des couches d’entreprise ou d’accès aux données si vous en avez besoin.
• Si vous envisagez d'écrire votre application de cette manière, vous feriez mieux d'utiliser un langage conçu pour fonctionner de la sorte, tel que PHP.

Vous feriez mieux de choisir des classes de couche d'accès aux données et aux entreprises non statiques:

• Utiliser le motif singleton (créer une seule instance de chaque classe et les partager entre les threads) ...
• Ou créer des instances des classes dans chaque fil au fur et à mesure de leurs besoins.

N'oubliez pas que chaque utilisateur / session connecté à votre application s'exécutera dans son propre thread. Par conséquent, votre application Web est multi-threadée.

Answer 2

Vous connaissez ces manèges au parc d’attractions où ils disent "gardez vos mains et vos pieds à l’intérieur du manège à tout moment". Il s'avère que le trajet est beaucoup plus amusant si vous ne le faites pas. Le seul inconvénient est que vous ne suivez pas vraiment une approche qui consiste à garder les mains et les pieds dans le vêtement.

Le problème est le suivant: il y a une raison pour laquelle vous devriez suivre une "vraie approche OO", tout comme il y a une raison pour garder vos mains et vos pieds à l'intérieur de la balade - c'est très amusant jusqu'à ce que vous saigniez partout.

Answer 3

Comme vous le décrivez, ce n’est pas le "faux" approche en soi, mais je ne vois pas vraiment le problème que vous essayez d’éviter. Ne pouvez-vous pas simplement créer une seule instance de ces objets métier au démarrage du serveur et les transmettre à vos servlets selon vos besoins?

Si vous êtes prêt à jeter OO par la fenêtre, vous pouvez également consulter le modèle Singleton.

Answer 4

Je ne vois pas vraiment l'avantage de votre conception, et de nombreux problèmes peuvent survenir. Vous enregistrez une ligne de code, peut-être? Voici quelques inconvénients à votre approche:

• Vous ne pouvez pas facilement remplacer les implémentations de votre logique métier
• Vous ne pouvez pas définir de variables d'instance pour faciliter la fragmentation de la logique en plusieurs méthodes
• Votre hypothèse selon laquelle les problèmes multithreads ne se poseront pas est certainement fausse
• Vous ne pouvez pas facilement vous moquer d'eux pour les tester

Je ne vois vraiment pas que l'omission d'une ligne de code vous achète quelque chose.

Ce n'est pas vraiment un " OO Design " question, mais plus d'une pertinence. Pourquoi utilisez-vous même Java de manière aussi procédurale? PHP conviendrait sûrement mieux à ce type de conception (et vous fait réellement gagner du temps en vous évitant de compiler et de déployer).

Je voudrais simplement rendre votre couche métier non statique; cela facilitera grandement la maintenance, la modification et l'évolution de votre application.

Answer 5

Vous aurez peut-être de la difficulté à tester vos objets avec ce type d’architecture. Par exemple, si vous avez une couche d'objets métier référençant votre couche d'accès aux données statiques, il peut s'avérer difficile de tester la couche métier car vous ne pourrez pas utiliser facilement des objets d'accès fictifs aux données. En d’autres termes, lors du test de votre couche métier, vous ne voudrez probablement pas utiliser le paramètre "réel". méthodes dans la couche d'accès aux données, car elles apporteront des modifications indésirables à votre base de données. Si votre couche d'accès aux données n'était pas statique, vous pouvez fournir des objets fictifs d'accès aux données à votre couche de gestion à des fins de test.

Answer 6

Je pense que vous rencontrerez des problèmes de simultanéité avec toutes les méthodes statiques à plusieurs utilisateurs. La couche Web séparera les utilisateurs concurrents. Toutes vos méthodes statiques peuvent-elles gérer cela? Peut-être, mais ne seront-ils pas constamment bloqués dans la file d'attente des demandes dans un seul fichier? Je ne suis pas sûr, je n'ai jamais essayé votre idée.