IoC and .NET framework

Question

I want to know what's the best practice with IoC pattern when dealing with .NET

For example, should I create SqlConnection / OracleConnection or any other provider through IoC container or with simple new keyword?

Does separating my class with concrete provider types has any value (including when I want to use only one type of provider)?

Answer 1

There is more to code maintenance than just swapping out one provider for another. For me, dependency injection is more about keeping the code logically separated and, thus, more maintainable, than it is about future-proofing the code for the day when a provider changes.

DI also allows you to reuse the code from one project to another more easily, because it makes the dependencies between the various parts more explicit.

That said, I have never used an IOC container, and I have never seen the need for one, so I cannot comment on that aspect of the question.

But you should definitely remove implicit dependencies from your code as much as possible, just to keep the code reusable, maintainable, and correct.

Answer 2

Injecting a SqlConnection or a IDbConnection would be pretty useless, because a DbConnection is a leaky abstraction. You can only use it to call stored procedures or simple SELECT * FROM VIEW type queries. Any more complex queries will be different per SQL dialect.

You will have a better change of succeeding when hiding the connection itself behind higher level abstraction, such as an IUserRepository or some kind. The default implementation of that interface would probably be a SqlUserRepository that would communicate with MS SQL Server, or a OracleUserRepository that communicates with Oracle.

Even better would it be to move away from the low level ADO.NET DbConnection API and move to an O/RM such as LINQ to SQL or Entity Framework. You would then typically have a LinqToSqlUserRepository .

Note that in that case I'm still talking about an XXXUserRepository . The interface still didn't change. In other words: IUserRepository is not a leaky abstraction. You can replace this interface for unit testing, while this is hardly possible when using a SqlConnection .

Answer 3

The IOC is there so that although you want to use one type of provider in reality someday somethings will change and you might need a secondary adapter so its best to use IoC instead of creating the object using new keyword. IoC is there for flexibility to change things as time goes by(as requirements change).

Answer 4

It would be good practice to use IoC even for .NET classes. This will allow your code to be tied only to an interface or base class if it is available. Not only that, but you can use your IoC framework to specify constructor arguments. This could be useful for connection strings in SqlConnection.

I should also mention that using IoC and writing code only to an interface will make unit testing much easier. This is particularly true when dealing with DB connections.

Answer 5

It could have value for unit testing if you use the IDbConnection and all the other classes instead of concrete classes.

Other than IOC and stuff like that, I've actually used the DbFactoryProvider ( some more info ) several times to create my Connections and other DB related objects, and read the provider through the ConnectionString.

The major problem with the DB stuff is that usually you can't really use only ANSI-SQL with the database, so while you are decoupled from the concrete classes your sql is not transportable. (i/e limit in MySql or Over and Partition in Sql Server).

About DI/IOC with other stuff that's not DB related it's great to decouple your classes and remove dependencies, and helps when unit-testing, say when you have a service you're working against This is helpful even when not in unit testing, when you are working against a service and another team is still developing the service you can create a fake service that just basically solves your problems (not all) so you can work against something, before the real service is availiable.

There are a lot more examples, but working against services (DB repository/web/authorization/whatever) is the first most straightforward added value.