I am having a really hard time reconciling IoC, interfaces, and events. Let’s see if I can explain this without writing a book.
I’m just getting started with IoC and I’m playing with Spring. We have a simple data layer that was built long before EF or the others. One of the classes is a DBProcedure which has some methods and events.
I created an IDBProcedure interface that the ‘real’ DBProcedure class implements. In TDD fashion I’d like to be able to swap out the ‘real’ DBProcedure class for another that implements the same interface for testing. To me, this means that the IDBProcedure interface should be defind in a different namespace/project than my data layer, right?
But a DBProcedure can raise some events and those events deliver custom EventArgs-derived classes. Does that mean that the EventArgs-classes need to be defined outside the data layer too? Seems like it to make the interface work, but that seems bad because it spreads data-layerness around?
On the other hand maybe I have the wrong idea – is it ok to include the data layer namespace when I’m testing to get interface and event definitions even though I’m not using any of the ‘real’ classes?
Yes, you need to move the interfaces and all the types it depends on somewhere, because you do not want the interfaces module to depend on the implementations.
The typical choice for this is one of two alternatives
(Implementation depends on api, client depends on api, everything in api module)
Here everyone depends on a common ‘model’ module, and this contains the enums and such. The advantage of this version is that you can have multiple API modules share the same common enums and other artifacts. (Because you really don’t want API’s to depend on other API modules usually)