Prism break #1: The Composite Application


The beginning

Change is the only constant in software development. However, not all the coding styles are easy to adopt changes, even though we consider that our “the code is very flexible“. For example, lets take a look to the following C#  sample:

var myConn = new SqlConnection(myConnectionString);
// perform some operations using the myConn instance.

At very first sight we might thing it’s flexible enough,… however it’s not as flexible as we might think. The only thing we can change is the connection string ( which only works for Sql Connections). We cannot specify a new data source e.g. MySql, SysBase, or a XML feed. So, is it really flexible?

Through the time developers have managed to hide this dependency by using composition and encapsulation. For example we can hide the fact that we are using an instance of SqlConnection by using composition:

public class Connection
{
   private SqlConnection myConnection;
   public Connection {
      myConnection = new SqlConnection("...");
   }
   // ... more public methods for users of this class
}

This approach seems to solve our dependency problem, however we still kinda of tight to the SqlConnection, we can argue that all the layers build over this Connection class, might depend of the SqlConnection class.

So, in fact if we would like to create tests, we will need to specify a SqlConnection to use our Connection class in middle layers. This might be painful if you consider that you’d like to create unit tests where each test will depend of the connection, instead of having more specific data sources to perform accurate tests.

So, what’s next? Simple, developers has used others ways to make the functionality less dependant of the implementation. A first approach is the pattern Dependency Inversion.Which tries to handle contracts (aka interfaces) instead of the concrete implementation of the contract. So, we can rewrite:

public class User
{
   IConnection _connection;

   public User (IConnection connection) {
      this_connection = connection; //
   }
   // ... public methods that depends on the Connection interface (contract)
}

In the previous example, it’s possible to take advance of the all the functionality provided by the connection without knowing if it’s a SqlConnection, MySqlConnection or even a XmlFile. The functionality is exposed by the contract, and we receive by parameter the implementation that has to be used by the class.  This makes the User class depend on the contract instead of the concrete implementation of the contract.

Certainly this model makes appear a new issue. In a supeior level of our structure the concrete implementation has to be instanciated, and this in fact is what makes our code less flexible.

public class UserView
{
   private IUser _currentUser
   public UserView (IUser currentUser){
      this._currentUser =  currentUser;
   }
   // ... so... where does the concrete implementation of User come from?

There are more patterns that solve the issue of the creation of objects, for example we can provide a class that
handles the instantiation of the objects. For example:

public class TopLevelClass
{
   private IUser _currentUser
   public TopLevelClass {
      this._currentUser = Creator.GetInstance<IUser>();
   }
   // ... more methods
}

In this example, the Creator class knows which concrete implementation of IConnection should used in the instantiation of User. This could be specified in a configuration file, or by code. This process of providing instances and injecting its dependencies is known dependency injection. Currently there are several frameworks that allows users to handle the instantiation of the objects in the application.

So, for changing an implementation for the entire application it might be as easy as change a setting in a configuration file, and provide a concrete implementation.

Prism and Dependency Injection

Composite application uses as Microsoft Unity to implement Dependency Injection. Even though the Unity library is already included with Prism, it’s optional to use it. Also, It’s possible to use other Dependency Injection framework, such as Microsoft Extensibility Framework (aka. MEF) which also is provided by Microsoft.

References:

Tame Your Software Dependencies for More Flexible Apps @ http://msdn.microsoft.com/en-us/magazine/cc337885.aspx

Regards,

Herberth

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s