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

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.