Application frameworks such as Spring.NET and Unity (there are others however I have used these 2 with great success) will cost you a little time up front in learning them however they will save you a ton of time as you add more features to your application. For many of you, this is not new and you're probably moving on to another blog but for some, it's a new concept. Why, after all, would we want to use a 3rd party application framework at all? It gets down to the old cliche of "not reinventing the wheel". For an application of any size, there are going to be dependencies. These dependencies can show up in the form of models, views, controllers, supporting classes, presenters, widgets, etc, etc. In a well designed n-tier application, it is ideal to have these dependencies expressed in the form of explicit interfaces especially in components that cross boundaries. By this, I'm referring to the definition of interfaces; the contracts that are guaranteed to be supported by any class that implements them (as opposed to the implicit interface which consists of all public method, properties and events).
This is where the application framework comes in. Rather than having your class you just instantiated create instances of all of its dependencies, the framework can instead serve up your class to the context. Fowler and others commonly refer to this as Dependency Injection. For most basic needs Unity can provide ample support for dependency injection. In many applications however, there will arise the need for things like custom factories where families of classes implement the same interface and are used at different times based on context. If those types of needs arise, Spring.NET might be a better choice as it already has the built-in capabilities in the form of factory methods. While you can achieve the same thing with Unity if you write extensions (at this time I'm referring to V1 not V2).
Likely, you'll also need support for things like logging and caching. Again, both Unity and Spring can provide these either through dependency injection or through their AOP capabilities.
If you are a steadfast Microsoft fan and use other capabilities like Enterprise Library, Unity will suit most of your needs. If however, you are open to other frameworks, I highly recommend taking a peek at Spring.NET. In Spring's latest release, there is now support for ASP.NET MVC 2 as well as the Windows Communication Foundation API. Previous support for ASMX services made it possible to create dynamic service proxies as well as services. When consuming services there is often a need to transform messages from services to a model for the client to consume. ASMX support was so well done, it was possible to share entities between service and client without the need for message transformation on the client side. Additionally, there is native support for NHibernate in Spring.NET.
Before I end up sounding like I'm doing a comparison of the two, I'll stop. The main takeaway for you should be to make it a Sprint Zero effort to compare the application frameworks out there, determine what your needs are then do a formal selection process to determine the best fit. By all means though, shorten your project life-cycle and use an application framework.
No comments:
Post a Comment