|Home||Back to Index|
The questions that annoy me are ones like this:
You’ve just coupled your application to the library. Yes, IDocumentSession is an interface. But it’s RavenDB’s interface. Does the class that you’re injecting it into call all of its methods? Does it use all of the properties of the interfaces returned by these methods? I doubt it.
You’re violating the Interface Segregation Principle.
Your class is also announcing, “I know I’m talking to a NoSQL database, or something like one, and that that database’s API looks exactly like RavenDB’s.”
It’s not just RavenDB. HttpContext, repositories using IQueryable<T>, interfaces of expressions of generic function delegates, you name it.
Does your class need all of that functionality?
Or does it just need a simple service?
Custom interfaces are easy to write, easy to implement (with a custom wrapper class), and easy to mock. They let you be explicit in your dependencies, specifying what a given class needs and no more. With a custom interface, you can also replace the actual implementation easily; you’re no longer wedded to a given library, technology, or product.
Time spent thinking about dependencies is time saved asking questions about mocking frameworks.