Exemple de mauvaise utilisation de Spring

Question

Notre magasin de logiciels fait un grand système d'entreprise et l'un de ses composants est un outil sophistiqué de surveillance et de visualisation de journaux. Récemment, un de nos membres l'a réécrit, car la version précédente manquait vraiment de certaines caractéristiques essentielles. Et c'était vraiment moche.

Depuis que cette équipe s'ennuie avec des trucs d'entreprise et ils ont entendu parler de IoC et Spring ("Semble être cool, ya?"), Ils ont pensé que c'est une bonne idée de l'utiliser dans cette application. En conséquence, j'ai environ 170 objets configurés via Spring (presque tous les vus dans l'application). Chaque objet simple est connecté via tag. Bien sûr, tout est un singleton, donc l'ajout d'une fonctionnalité comme le traitement de fichiers multiples est presque impossible. Puis-je supposer que l'utilisation de Spring de cette façon est assez «controversée»? Je pensais que IoC et Spring répondaient à d'autres besoins (comme le changement de pilote de base de données ou d'autres configurations dynamiques).

EDIT: GUI de cette application est un peu similaire à Visual Studio GUI. J'ai donc un onglet avec le fichier journal (et c'est un composant Spring). J'ai un onglet pour les signets (un composant Spring). Et donc un: imaginez que pour chaque onglet dans Visual Studio, vous avez un composant Spring. Et chaque composant a une interface uniquement capable de se connecter avec un autre composant unique.

Il est donc possible d'avoir à créer des onglets (configurer deux composants). Mais cela signifie deux fenêtres de signets (ce qui n'a aucun sens - dans VS vous avez un pour chaque fichier).

@Earwicker: presque chaque classe dans ce projet est configuré via Spring (de chargeur de fichier, le fichier indexeur, onglet signet, onglet Fichier, onglet coloriseur)

Answer 1

D'après votre description (comme d'autres l'ont dit), il est impossible de juger si la conception résultant est bon ou mauvais.

L'extrême ultime du CIO ressemble à ceci: chaque API utile est enveloppé dans une classe de composant.Les paramètres de cette API sont fournis par d'autres composants. Par exemple, si l'application peut avoir besoin de lire un fichier, vous auriez un composant (en pseudocode):

public class ReadFile : IStreamFactory 
{ 
    IFilePath _path; 

    public ReadFile(IFilePath path) 
    { 
     _path = path; 
    } 

    // implementing IStreamFactory 
    Stream Get() 
    { 
     return new FileStream(_path.GetPathString()); 
    } 
} 

Alors maintenant faire l'objet capable d'ouvrir un flux sur un fichier, vous devez écrire un autre composant qui implémente IFilePath. Vous pouvez écrire plusieurs: un composant qui stocke un chemin de fichier constant (lu depuis la configuration, bien sûr!), Un composant qui combine deux chemins de fichiers, un composant qui prend du texte en clair d'un autre composant (implémentant une autre interface, ITextSource?) que c'est un chemin valide.

Vous avez l'idée, de toute façon. C'est presque comme si vous preniez chaque ligne d'une application ordinaire et que vous faisiez de cette ligne unique un composant séparé. Un autre exemple:

class IfThenElse : IAction 
{ 
    IBoolean _test; 
    IAction _ifTrue; 
    IAction _ifFalse; 

    // omitting obvious constructor 

    // implementing IAction 
    void Do() 
    { 
     if (_test.GetBool()) 
      _ifTrue.Do(); 
     else 
      _ifFalse.Do(); 
    } 
} 

Vous aurez besoin d'autres composants représentant un « cadre dans lequel les variables peuvent être déclarées », et une « déclaration variable nommée » et une « référence à une variable », qui doit en quelque sorte être en mesure de travailler sur n'importe quel type de composant. Alors vous avez maintenant besoin de lier tous ces minuscules fragments ensemble dans un gigantesque fichier de configuration XML, pour les assembler tous ensemble dans une application.

Si vous avez vraiment fait cela au niveau le plus bas possible, ce sera assez absurde, car la tâche d'écrire le fichier XML sera comparable à l'écriture d'une application de la manière habituelle. Sauf que la syntaxe sera basée sur XML, les noms de toutes les fonctions seront complètement non standard, et le support de débogage sera nul. Si vous pouvez trouver un "sweet spot" quelque part au-dessus de cela, alors votre format XML pourrait être quelque chose que les utilisateurs préféreront, et trouveront plus facile à apprendre, que la programmation "brute" dans le langage sous-jacent.

This is very similar to a point I made the other day about XAML.

Answer 2

Quand vous dites « tout est un singleton » voulez-vous dire que c'est comme ça que ça se passe d'être configuré au printemps? Je ne m'attendrais pas à ce que les types eux-mêmes (en code) soient des singletons - en effet, une partie du point de pouvoir configurer les choses avec IoC est d'éviter les singletons authentiques (qui rendent les tests plus difficiles, par exemple).

Je ne peux pas deviner vraiment la meilleure façon de mettre en œuvre le « support de fichiers multiples » vos question parle sans voir le code - mais il ne devrait certainement pas être trop difficile. Vous pouvez l'approcher de différentes façons, soit en injectant une usine pour le composant approprié, soit en laissant votre application demander à Spring de créer des composants quand cela est nécessaire. (Ce dernier est plus invasif en termes de dépendances à Spring, mais peut signifier moins de code de chaudière.)

Il est très difficile de juger du code sans le voir, mais en créant une application complexe via un grand nombre de composants faiblement couplés. configuré en utilisant Spring ne me semble pas trop mauvais.

Answer 3

configuration dynamique (comme la modification d'un pilote de base de données ou le remplacement d'une couche avec une maquette pour le test) est seulement l'un des nombreux avantages du printemps et IoC en général. Peut-être que le principal avantage est la séparation complète des préoccupations. Tous les objets deviennent indépendants les uns des autres, effectuent une tâche spécifique et il est de la responsabilité du conteneur de les relier entre eux.

également au printemps le singleton concept est en quelque sorte différent de modèles de conception singleton. Je dirais que l'utilisation de l'IoC est appropriée pour chaque application de taille moyenne ou grande. Peut-être que les développeurs n'étaient pas très expérimentés avec Spring et n'utilisaient pas certaines des techniques les plus avancées, ce qui réduit vraiment la taille du code et produit un résultat plus élégant.

Answer 4

Dans l'expérience que j'ai eu au printemps, je aurais tendance à aller pour une architecture qui ne les haricots que vous savez singletons devraient être gérés par Spring. Les autres haricots devraient plutôt être gérés par code dans ces haricots de printemps. lentement, manuellement.

De cette façon, il y a une forte séparation entre ce que fait le ressort et ce que fait l'application. Il devient difficile d'utiliser le printemps, et c'est un avantage si vous l'utilisez pour les objets non singleton dans votre contexte, comme vous le faites actuellement. Je reconnais que cela ne sera pas valable pour toutes les situations, mais il semble que cela puisse s'appliquer dans les vôtres.

Answer 5

Le printemps est là pour vous aider à ne pas entraver ou vous limiter, mais pour nettoyer tout le code de la plaque de la chaudière ne veut voir ou écrire ainsi que le support de test/db etc etc

Il est vrai que ce techniquement, il est possible d'échanger une implémentation de persistance par exemple, mais en réalité cela arrive rarement et cela aura un impact sur vos interfaces, peu importe comment vous pensez qu'elles sont agnostiques.

Une meilleure raison d'utiliser Spring est celle que j'ai déjà mentionnée; test ...

Je ne suis pas votre commentaire concernant tout est un singleton, si c'est le cas c'est une décision prise par votre architecte car vous pouvez avoir des non-singleton ou des prototypes au printemps et sont encouragés à le faire Donc, si nécessaire, pour éviter les modèles de domaines anémiques et les classes qui semblent procédurales ou scriptées.

Il n'est certainement pas difficile de travailler avec des objets prototypes au printemps. Rappelez-vous, sous tout l'extérieur brillant et IoC, le ressort est simplement une usine.