Inverson of Control (IoC) is a very powerful concept. The basic premise of IoC is to invert elements of your programming paradigm for flexibility and extensibility. Most procedural or OO code the linkages are hard code. Most data access code, take DAO for instance, need a handle to a connection object. Fortunately if you are using a good persistence framework like NHibernate you don't have to directly deal with the ADO Connection object as it handles that for your, however you need to efficiently manage an NHibernate Session.
How to do so is very important in ASP.Net applciations as you may have dozens of request per second and if you handle this poorly your application performance will suffer. Handle it well and you will often have better performance than straight ADO.Net applications.
Let's take two simple application layers UI and Data Layer. Our data layer contains our DAOs (data access objects) which perform direct interaction with our database and of course our UI contains all necessary user interface related code.
UI Code
The public setter that we declare here exists for dependency injection (DI), this will allow Spring.Net to set (or inject) our dependencies for us. We configure Spring to set this pages dependencies in our configuration file like the following:
This section is telling Spring that the page (Applications/Default.aspx) has a property named GenericAppSectionDao which needs to be set to a reference of an object named GenericAppSectionDao
At your applications first run (first request for a website) Spring will create all of these objects in memory for you and set them up (unless you configure them differently of course). This requires an upstart cost but saves performance with each request after the first.
Next we need to tell Spring how to create this object GenericAppSectionDao:
At your applications first run (first request for a website) Spring will create all of these objects in memory for you and set them up (unless you configure them differently of course). This requires an upstart cost but saves performance with each request after the first.
Next we need to tell Spring how to create this object GenericAppSectionDao:
The first object element creates an abstract object so that Spring knows to create before the objects that are dependent on it. Next we tell Spring to create an instance of a generic class called Dao that provides basic Dao functions and we tell Spring that it's dependent upon BaseDao (again so that Spring knows to create this object after it creates its parent). The generic Dao class looks like the following:
Lastly is BaseDao which provides a public setter to set the SessionFactory with a public Getter to get the current session. This enables SessionScopes which are a good idea for web apps. BaseDao code is below
You could obviously perform the same exact methods with any IoC framework (Castle or anything else). The only difference should be the XML files. Dependency Injection (DI) is a form of IoC and reinforces best practices for writing proper unit tests because you can isolate each layer you are testing and mock its dependencies. It also facilitates AOP so you can do all sorts of stuff (transactions, logging, etc) between application layers automatically.
2 comments:
Does Spring.Net offer a way to bootstrap its congiguration other than in XML? Have you tried using Castle, Structure Map, Ninject as alternatives?
I started off using Castle and migrated to Spring. You can load or register objects in C#, one way is like this:
IConfigurableApplicationContext ctx = new GenericApplicationContext();
ctx.ObjectFactory.RegisterSingleton("MyObject", myObjectInstance);
Castle has similar XML format and it's a good framework in it's own right, I chose Spring because it has more features besides the IoC container.
Post a Comment