Microsoft Enterprise Library 5.0

The Microsoft patterns & practices team is gearing up for development on the next release of Enterprise Library, Enterprise Library 5.0. There are some key architectural changes and new blocks available. Since we are still in early release they are asking for your input.

For those not familiar with the Enterprise Library (EntLib) see the description and link below:

The Microsoft Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development challenges. Application blocks are a type of guidance; they are provided as source code plus documentation that can be used "as is," extended, or modified by developers to use on complex, enterprise-level line-of-business development projects.

http://www.codeplex.com/entlib

The Doublemint Twins

Enterprise Library 4.0 (and 4.1) actually had two ways of locating and building object for its various blocks: through static factories or through a Unity dependency injection container.


Actually, having two approaches to building up objects in Enterprise Library 4.0 was intentional. Honest. Really. I mean it. While it may seem a bit odd, this was an intermediate step to moving entirely to a container approach for Enterprise Library.

This move is important for a number of reasons (and not just because we also wrote the Unity container). First, this is important because the static factory approach does not work well for those people who use containers in their applications and want to be able to get Enterprise Library objects from their container. Second, it is important because the instance factories in Enterprise Library 4.0 are handling things that containers are designed to handle, such as lifetime, location, and object creation. It doesn’t make sense to build and maintain these specifically for Enterprise Library.

Enterprise Library 4.0 took a step towards the container world by providing an approach to

configuring a Unity container with the appropriate Enterprise Library pieces. However, this means that you generally want to use either the static factory approach or the container approach, because objects created in one approach do not work with objects in another approach. We were really maintaining two sets of objects and building strategies (that is, the approach to building up those objects in case we need to rebuild them).

As the final step towards moving to using a single container, we now have the static/instance factories that rely on the same container that you could configure independently.



So you can use the static factories, instance factories, or the container and they will all work together.

While this sounds easy, plugging container B into slot A is not as straightforward as you might think. To start with, Enterprise Library 4.0 relied on many ObjectBuilder internals to build objects and frequently would apply configuration during object creation:



We wanted to use the containers in a more traditional way, namely by providing the configuration ahead of time and then using the container to resolve objects, so now we configure the container the first time something needs to be resolved:



After the container has been configured, the EnterpriseLibraryContainer will directly reference the UnityContainer.

Why Can’t We All Just Get Along?

Aside from making the Enterprise Library story a bit cleaner, moving to a container-based approach has another benefit; it makes it easier to provide support for other containers to work with Enterprise Library. By default, the EnterpriseLibraryContainer provides EnterpriseLibrary objects through a UnityContainer but it does so through the IServiceLocator interface provided by the Common Service Locator project. The Common Service Locator was a join effort of thought leaders and key contributors representing various containers (including Unity, Spring.NET, Castle/Windsor, MEF, StructureMap, Ninject).

The IServiceLocator serves as a plug point for Enterprise Library to work with a container other than Unity. The IServiceLocator only deals with how to acquire object instance, we also needed a way to let a container know how it should be configured to support Enterprise Library without letting Enterprise Library know anything about a specific container. We provide this configuration information in a container agnostic way through a set of TypeRegistrations. Generally, a type registration will contain information about how a type should be built (what constructors and parameter values to use, whether to create them as a singleton or instance each time, and what properties to set on the type). Here’s a typical type registration:

1: new TypeRegistration<Database>(
2: () => new SqlDatabase(
3: ConnectionString,
4: Container.Resolved<IDataInstrumentationProvider>(Name)))
5: {
6: Name = Name,
7: Lifetime = TypeRegistrationLifetime.Transient
8: };
9:
Type registrations are specified as expression trees as it makes them a bit easier to read and they tend to work better when refactoring code. The above registration can basically be interpreted as ‘register a type Database named Name that is mapped to a new instance each time of type SqlDatabase and use the constructor that takes a ConnectionString and an IDataInstrumentationProvider (oh, and by the way, can you pretty please resolve that from the container too?)’.

These registrations are processed by a configurator that knows how to apply them to a specific container. Enterprise Library provides a UnityContainerConfigurator, but you can use any other IContainerConfigurator. The general configuration process looks like this:



Configuring Enterprise Library, given a configuration source and a container configurator can be done like this:

1: var configurator = new UnityContainerConfigurator(Container);
2:
3: EnterpriseLibraryContainer.ConfigureContainer(
4: configurator,
5: configurationSource);


Hopefully this gives you a little deeper understanding of the motivation and content for recent changes in Enterprise Library. In future posts, I hope to go into a bit more depth around how we find type registrations and some of the cleanup we did around instrumentation.

Application Blocks

Do you want to see new application blocks, bug fixes, new application block providers? Currently there are the following application blocks:

Data Access Application Block
Logging Application Block
Validation Application Block
Security Application Block
Caching Application Block
Exception Handling Application Block
Cryptography Application Block
Policy Injection Application Block
Unity Application Block


Any of those application blocks not work as expected and/or do not integrate with particular technologies of interest? Perhaps one of the application blocks needs more functionality or you have an idea for a new application block?

Now is the time to get your voices heard as this time only comes around once a year and the year can feel like a very long time ;) You have a $100 to spend on how you want patterns & practices to focus their time on Enterprise Library 5.0 so think about your priorities and leave a comment on Grigori's blog here.

Tags: Architecture, EntLib, Microsoft

Comments

[Wes]

Hi Mike,

I have read your article in detail and I do agree with you that having two ways of locating and building object for various blocks did seem odd. I appreciate your work towards adopting container approach. But I want to draw your attention towards another important issue. I have found an article on internet which talks about The Limitations of the Cache Application Block from Microsoft Enterprise Library. According to that article ASP.NET apps frequently run in web farms for scalability reasons. A stand-alone cache is unaware of multiple servers and cache instances and is not synchronized. This leads to data integrity problems. I will highly appreciate if you could please read this article and give your suggestion as well as recommendations.

Cheers.