views:

57

answers:

2

With IOC I understand you can substitue implementations out by merely editing a configuration file etc.

BUT, what happens when the classes are married to particular database tables and sprocs, you can't just swap out an implementation since the classes/entities are tied to particular tables and stored procedures.

Am I right here?

+4  A: 

When you inject an instance of class A into an instance of class B you are doing so on the basis that A fulfills a contract upon which B can rely, usually specified by an interface (but can also be done by a class or superclass). If B doesn't satisfy that contract, behaviour is undefined.

So it comes down to that: when you interact this way you shouldn't be concerned with do table structures match or not. You should be concerned if the interface is correct.

Also, these kinds of OO entities in an ORM sense don't tend to be injected, in my experience. Typically injection happens with service providers.

cletus
This substitution ability you refer to is known as the Liskov Substitution Principle.
vanslly
+1  A: 

What cletus was saying...

public class CustomerService //may implement extend from some base
{
   public ICustomerDao customerDAO { get; set; } //the injected object

}

CustomerService is your business level class (for instance) where you can inject some CustomerDao with dependency injection using an IoC container. What you can inject is defined by the contract of ICustomerDao. So everything implementing that will be allowed to inject here.

Juri