I am trying to implement Dependency Injection to make my app tester friendly.
I have a rather basic doubt.
Data layer uses SqlConnection object to connect to a SQL server database.
SqlConnection object is a dependency for data access layer. In accordance with
the laws of dependency injection, we must not new() dependent objects, but rather
accept them through constructor arguments. Not wanting to upset the DI gods, I
dutifully create a constructor in my DAL that takes in SqlConnection.
Business layer calls DAL. Business layer must therefore, pass in SqlConnection.
Presentation layer calls Business layer. Hence it too, must pass in SqlConnection
to business layer.
This is great for class isolation and testability. But didn't we just couple the
UI and Business layers to a specific implementation of the data layer which happens
to use a relational database?
Why do the Presentation and Business layers need to know that the underlying data store
is SQL? What if the app needs to support multiple data sources other than SQL server
(such as XML files, Comma delimited files etc.) Furthermore, what if I add another object
upon which my data layer is dependent on (say, a second database). Now, I have to
modify the upper layers to pass in this new object.
How can I avoid this merry-go-round and reap all the benefits of DI without the pain?
