Page 2 of 2   « previous page

Application Configuration
In the past, many of our applications had their own way of retrieving their settings. The registry keys and configuration files were mainstream but there was no standardized higher-level approach to apply the lower-level configuration APIs consistently across the application. As a result, we essentially wrote all the code necessary for the whole application configuration in multiple ways in some ad hoc Init() method, resulting in duplicate code if a specific setting was reused across applications. This proved a development and deployment nightmare, since there was always a strong dependence on the configuration code.

Using Spring.NET, we can easily apply a comprehensive approach to application configuration instead of writing such functionality in-house. Objects that need some setting are simply "given" it through the dependency injection mechanism, using simple setter properties or even constructors. The source of these values can come from practically any source, such as the registry, configuration files, or custom providers. As an added benefit, with Spring.NET, we can configure each object separately - no need to configure the whole application at once - which is the direction that previous approaches to configuration led us towards.

Declarative, Distributed Transactions
Most of our business logic was written in Delphi, C++, or .NET serviced/enterprise components and made use of COM+ transactions; or worse, data access code managed their own transactions using the likes of BeginTrans() and RollbackTrans(). Some stored procedures did their own transaction-handling as well. Changing the transaction management strategy was difficult, since it was hard-coded. It also made debugging transactions and locking problems very hard, including all the MSDTC deployment problems.

Now we can abstract transaction management APIs away from the service layer code and into external configuration using Spring.NET's declarative transaction management features. Using simple C# attributes to hint about the transactional requirements of a specific service method, such as which exceptions should trigger a rollback, we can declaratively apply transactional functionality to the service layer. At a high level, Spring.NET lets us say, using a simple attribute: "Before this method, start a transaction; after this method, stop transaction; if it throws an exception, rollback."

Great technology from Microsoft, like TransactionScope transactions, which allow for automatic promoting from local (one single resource/database) to distributed (multiple different databases), is available to developers via Spring.NET. Spring.NET provides a transaction provider abstraction, letting you switch from using TransactionScope-based transaction management for distributed transactions to standard ADO.NET-based transaction management for local (non-distributed) transactions.

Business Logging via AOP
The nature of our business mandates that we have a very high level of logging. Most operations, from the simple create/insert/delete of a cost-center entity to the complex multi-item purchase order editing, had to be logged and traceable. This generally means that teams had to write specific logging code for each and every operation, leading to a complex mix of actually implementing the requirements and logging what was being done.
Using Aspect-Oriented Programming (AOP), we can now simply declare logging as an aspect and declaratively apply it to the relevant points in our system instead of writing similar logging statements in the code in hundreds of locations. In practice, Spring.NET lets us handle logging just like it handles transactions. We can define a logger object (in which we capture user context information, thread states, parameter values, etc.), inject its dependencies (e.g., the database where we persist the captured information), and apply it, via external configuration, to our business methods. Spring even lets us piggyback the logging advice on to the transactional advice, since most of the same methods that are transacted also need to be logged. For more information on Aspect-Oriented Programming see to the Wikipedia article http://en.wikipedia.org/wiki/Aspect-oriented_programming.

Exposing POCOs as Web Services or COM+ Components
Exposing the same functionality over different channels required us to duplicate a lot our code, or, at least, write different "wrapper" classes to adapt to each technology's requirements. Web Services require WebMethod annotations; COM+ components need to extend ServicedComponent, remoting calls for MarshalByRefObject, etc.

Spring.NET lets us expose our service implementations (which are actually POCOs, Plain Old C# Objects) as Web Services or enterprise services (COM+) using simple external configuration files. The great thing about this is that we can keep all the transactional and logging benefits while reusing a lot of code. In this way, a service method that was originally written for an ASP.NET page can be very simply reused when exposed as a Web Service, which is called by our Adobe Flex clients over HTTP. There's even no need to write wrapper .asmx files or classes.

Conclusion
When planning a new .NET application, or architecting a large migration to the .NET platform, it's important to keep in mind that even though a lot of frameworks are available, some are too cumbersome and demanding, or too much of an all or nothing deal. A good framework should "push" you in the right direction, make it easy to apply successful approaches, and marry best practices and reusable code artifacts in a way that actually improve application quality. We found this and more in the Spring.NET Framework, which is a spiritual port of the Spring Framework, famous and highly praised in Java circles. We could learn from the framework while it adapted to our needs and enjoy consistent development and excellent runtime performance in the .NET world. (See sidebar)

Page 2 of 2   « previous page