Question simple: je comprends que la sérialisation en C # nécessite des constructeurs par défaut. Cela éliminerait la possibilité d'utiliser DI injecteur constructeur (qui est généralement le style préféré de DI, dans ma lecture [citation nécessaire] ). Alors, est-ce vraiment une situation ou, ou manque-t-il quelque chose?
(Question secondaire): Les conteneurs IoC annulent-ils en quelque sorte ce compromis?
This would eliminate the possibility of using Constructor injected DI-- Pourquoi? Vous pouvez toujours avoir des instructeurs paramétrés, tant que vous incluez un constructeur par défaut à des fins de sérialisation (le constructeur par défaut peut être privé, si vous le souhaitez).Réponses:
Il n'est pas possible de désérialiser un objet et d'injecter également une dépendance à un autre objet déjà existant, en une seule étape en C #, en utilisant les mécanismes de sérialisation standard. Vous devrez utiliser l'injection de propriété à la place, en construisant d'abord l'objet à l'aide du désérialiseur, puis en injectant la dépendance. Pour la plupart des applications du monde réel, je ne considère pas cela comme un véritable inconvénient - si vous avez une classe de modèle de données sérialisable, qui a également des dépendances avec d'autres classes de modèle non-données, vous devez vérifier si votre classe de modèle de données peut avoir trop de responsabilités déjà.
Si cela vous dérange vraiment, vous pouvez envisager d'encapsuler votre objet sérialisable avec une classe décoratrice, où vous pouvez passer le désérialiseur et les dépendances supplémentaires via le constructeur. Ce wrapper exécute ensuite les deux étapes (désérialisation de l'objet encapsulé et injection de propriété) dans son constructeur.
la source
Je résous ce problème comme ça: injecter des usines de dépendances. Dans ces usines, résolvez d'abord la dépendance telle qu'elle est enregistrée dans le conteneur, puis "désérialisez" toutes les données restantes: json.net permet de remplir les champs de l'objet existant.
Comme le code des usines va de pair avec le code de câblage du conteneur IoC, je ne pense pas que l'utilisation à l'
container.Resolveintérieur de l'usine viole la règle, quicontainerdoit être utilisée à un seul endroit dans le code: où tout le câblage se produit.À partir de maintenant, j'essaie de rendre ce processus automatique (par opposition à ce que j'ai testé cette approche) en utilisant la réflexion. Oui, il ne reste pas grand-chose de la désérialisation de json.net elle-même, une partie est remplacée par du code personnalisé, mais je pense, pourquoi s'embêter.
En outre, quelles ont été vos dernières réflexions / décisions sur la question? Après avoir lu ce post, je vois deux façons: désérialiser, puis injecter; ou injecter, puis désérialiser (remplir). Et je trouve toujours que mon chemin est meilleur. Je serai heureux d'entendre des arguments en opposition à cela (je pense que ma voie peut être meilleure pour mon cas, mais je ne peux pas imaginer de manière vivante de bons cas alternatifs, où cela échoue, juste quelques suppositions mineures)
la source