Apr 30, 2014

A very important aspect of software engineering is the maintainability and extensibility of the code base. One way to write maintainable code is through loose coupling. In this context coupling refers to the degree of direct knowledge among classes. In a loose coupled system the methods of a class depend on simple types like String, Integer, Boolean, etc. or they depend on interfaces, but never on concrete class types. So for example, if in our system we have a class Invoice with methods that rely on instances of the classes Customer and Product we should have the corresponding interfaces definitions ICustomer and IProduct and those interfaces would be the data types for the methods of Invoice that receive a Customer and/or a Product as input. Also if any of these classes are going to call methods defined in other classes we should not hardcode the specific concrete types of those external classes but always use an interface. Dependency Injection (DI) is a design pattern that enables loose coupling. Let’s have a look at how you can implement DI in C# by first principles with a very simple example.

public  class Customer { private IDataService _dataService = null; //Inject  the dependency via a constructor public Customer ( IDataService dataService ) { _dataService = dataService; } …. }

The above class is receiving everything it needs through its constructor. The interface IDataService would define the signature of all the methods the Customer class would need to access a database where the information about customers are permanently stored, but not how those methods are implemented. Our system could make use of whatever concrete classes that implement the IDataService we may have. So we could in some places instantiate a Customer passing a SQLDataService class, in other places we could have an OracleDataService class for example. As an alternative to the injection via a constructor we could simply have some setter properties or methods we use to decide at run time which concrete instances of the interfaces we will pick depending on the particular circumstances. We could even combine both approaches. There are frameworks that can help automating the dependency injection process. So I could for example use a config file where we map interface names with concrete classes which could be in external assemblies and the framework would be able to read the web.config or the app.config file and instantiate the right class at run time. Examples of DI frameworks are Spring.NET, Unity, StructureMap, MEF to name a few. To learn more about writing high quality C# code using DI and many other design patterns I would recommend New Horizons' course 20483: Programming in C#.