IoC et les événements

Question

J'ai vraiment du mal à réconcilier l'IoC, les interfaces et les événements. Voyons voir si je peux expliquer cela sans écrire un livre.

Je ne fais que commencer avec IoC et je joue avec Spring. Nous avons une couche de données simple qui a été construite bien avant EF ou les autres. L'une des classes est DBProcedure qui a quelques méthodes et événements.

J'ai créé une interface IDBProcedure que la classe DBProcedure 'real' implémente. En mode TDD, j'aimerais pouvoir remplacer la vraie classe DBProcedure par une autre qui implémente la même interface pour les tests. Pour moi, cela signifie que l'interface IDBProcedure doit être définie dans un autre espace de noms/projet que ma couche de données, n'est-ce pas?

Mais un DBProcedure peut déclencher certains événements et ces événements fournissent des classes dérivées EventArgs personnalisées. Cela signifie-t-il que les classes EventArgs doivent également être définies en dehors de la couche de données? On dirait que ça fait fonctionner l'interface, mais ça a l'air mauvais car ça étale la data-layerness? D'un autre côté, peut-être que j'ai une fausse idée: est-ce que je peux inclure l'espace de noms de la couche de données lorsque je teste pour obtenir des définitions d'interface et d'événement même si je n'utilise aucune classe?

Answer 1

Oui, vous devez déplacer les interfaces et tous les types dont il dépend quelque part, car ne veut pas que le module d'interface dépende des implémentations.

Le choix typique est l'une des deux alternatives

Impl ----> Api <---- client 

(mise en œuvre dépend de api, client dépend api, tout dans le module api)

Impl ----> Api <----- client 
\   |  /
\   V  /
    ------->Model<------ 

Ici tout le monde dépend un module "modèle" commun, et qui contient les énumérations et autres. L'avantage de cette version est que vous pouvez avoir plusieurs modules API partageant les mêmes énumérations et autres artefacts communs. (Parce que vous ne voulez surtout pas que les API dépendent des autres modules de l'API)