Inside A Developer's Head

Finally, Spring.Net team developed a new extension for Spring.Net to allow developers configure their objects through code. They have simply named it CodeConfig.

A part of class structure for an Order Management system can be assumed as below:


//Data Access Objects
public interface IDao<T> where T:class
{
T[] GetData();
}
public abstract class RelationalDatabseDao<T> : IDao<T> where T : class
{public abstract T[] GetData();
}
public abstract class NoSqlDao<T>:IDao<T> where T:class
{
public abstract T[] GetData();
}public class MongoDbDao<T> : NoSqlDao<T> where T : class
{
public override T[] GetData()
{
//return data here
}
}public class SqlServerDao<T> : RelationalDatabseDao<T> where T : class
{
public override T[] GetData()
{
//return data here
}}
//Order Service
public interface IOrderService
{
IDao<Order> OrderDao { get; set; }
IEnumerable<Order> GetAllOrders();
}
public class OrderService:IOrderService
{
public IDao<Order> OrderDao { get; set; }
public IEnumerable<Order> GetAllOrders()
{
return OrderDao.GetData();
}
}

In order to have configurations in code instead of inside XML files, we need to create class alternatively for each XML configuration file. Suppose we had the below XML inside configuration file called Config.xml :


<objects xmlns="http://www.springframework.net">
<description>An  example that demonstrates simple IoC features.</description>
<object name="dao1" type="Spring.NetSpike.SqlServerDao<Spring.NetSpike.Order>, Spring.NetSpike"/>
<object name="dao2" type="Spring.NetSpike.MongoDbDao<Spring.NetSpike.Order>, Spring.NetSpike"/>
<object name="OrderService" type="Spring.NetSpike.OrderService, Spring.NetSpike">
<property name="OrderDao" ref="dao1"/>
</object>
</objects>

The XML configuration files believed to become messy in time and difficult to maintain. It also happens that developers mistype a class name or forget to mention assembly names in XML configurations.

The XML configuration above can be translated to a class like the following:



[Configuration]
public class Configs
{
[Definition]
public virtual IDao<Order> OrderSqlServerDao()
{
return new SqlServerDao<Order>();
}
[Definition]
public virtual IDao<Order> OrderMongoDbDao()
{
return new MongoDbDao<Order>();
}
[Definition]
public virtual IOrderService OrderService()
{
return new OrderService(){OrderDao = OrderSqlServerDao()};
}
}

The method of retrieving objects from the IoC Container needs to be changed slightly. First we need a new instance of CodeConfigApplicationContext and call a method to scan through assemblies (or some of the assemblies) to find configuration classes. The Spring.Net core then finds the classes with Configuration attribute to initialise the objects.


 static void Main(string[] args)
{
var context = new CodeConfigApplicationContext();
context.ScanAllAssemblies();
context.Refresh();var orderService= context.GetObject("OrderService") as IOrderService;
Console.WriteLine(orderService.GetAllOrders().Count() + " orders were returned.");
}

Some points:

We can have a cleaner solution without XML configuration files

Typing mistakes in configuration files are reduced as a compile error is raised if we mistype a class name.

A negative point about CodeConfig is that Autowiring is not supported yet.

There is not a tangible decrease of load time as expected due to avoidance of XML parsing overhead.

Spring.Net Configuration in Code (CodeConfig)