Enterprise Library

[Tom Whitner]

Boy, it sure is quiet here.....

Over the past week, there has been quite some hype around Microsoft's Enterprise Library product. See http://www.gotdotnet.com/workspaces/workspace.aspx?id=295a464a-6072-4e25-94e2-91be63527327 for more information. They are proposing a different model for "wiring-up" components. In addition, they provide implementations for other components like data access and caching. We are facing the decision of which metaphor to embrace: Spring.NET or Enterprise Library. EL is nowhere near as flexible as Spring.NET, but (1) it is simpler, (2) it has MS behind it, (3) it comes with other infrastructure functionality already implemented, ands (4) it is due to release by January.

I am curious to here some of the Spring.NET team members' positions on this decision point.

- Tom

[Anonymous]

We are facing the decision of which metaphor to embrace: Spring.NET or Enterprise Library. EL is nowhere near as flexible as Spring.NET, but (1) it is simpler, (2) it has MS behind it, (3) it comes with other infrastructure functionality already implemented, ands (4) it is due to release by January.
Bear in mind that the patterns&practices stuff typically doesn't have the full 5+2 support cycle that official Microsoft products do, and that technically Avenade owns the IP (or at least part of it) for the EntLib stuff, which may make a difference to you or your company's lawyers.

If you're needing to start development now, I wouldn't wait, but if you can wait, it certainly doesn't hurt to do so until January (actually December) when the EntLib stuff comes out. We (the GAPP group) will probably be talking about EntLib at the next patterns&practices Summit, but that's probably not going to be until March sometime.

Ted Neward
http://www.neward.net/ted/weblog

[choyrim]

Both are in their early stages. So I think you should hedge and go with both. Nothing about Spring.NET precludes the use of Enterprise Library (or any other library for that matter). Pick and choose the pieces your team likes better.

For example, you could go with crypto libs from the Enterprise Library and AOP Transactions (not implemented yet) from Spring.NET. You do have to choose between one of the configuration models. But if the demand is good, we'll get Spring.NET to play nice with the Enterprise Library. We already have plans to integrate smoothly with System.ComponentModel.

That said, I think you should put your EL blocks inside the Spring.NET container instead of the other way around. I suspect that the Spring container is more flexible in terms of configuring your top-level objects. It's tempting to think of your application in terms of the database access, security, and logging it's gotta do. But often, keeping your interdependent components decoupled is just as much effort. Spring is particularly good at making it easy to maintain low coupling while configuring and wiring interdependent components.

--Choy

[Mark Pollack]

Hi Tom,

IMHO, the general principals that were used to create Spring.Java also apply in the .NET world. Spring is not about replacing existing implementations of core infrastructure services (i.e. transaction managers), but is about making standard technology easier to use. Often this may be nothing more than providing a ‘FactoryObject’ for a particular class library to facilitate its use the IoC container.

As Choy says, there is no reason you can’t use some EL blocks in your code and have Spring wire up your applications. I did not see the approach the EL is using to “wire-up” these blocks. If it is at all like a service locator approach, using Spring doesn’t prevent you from doing this ‘under-the-covers’ configuration inside a class created by Spring’s object factory. I would say the service locator approach isn’t preferred, but nothing prevents you from doing it.

Spring also offers AOP support, which may or may not be important to you. The logging EL block looks like direct competition with existing solutions, such as log4net. I’m sure there will be quite some debate about that. I’m glad the logging EL block removed the dependency on the Enterprise Instrumentation Framework, which was very heavyweight.

For data access, I believe adapting the Spring.Java’s approach to data access provides a lot of value in the .NET world. A unified data access exception hierarchy (http://www.springframework.org/docs/reference/dao.html) across all DB/ORM providers is a great idea. An ‘AdoTemplate’ akin to the JdbcTemplate will support a provider independent API for ADO.NET along with exception handling functionality that removes the need to write tedious boiler plate exception handling code. Lofty goals I know... The goals for DAAB are similar to this but I don’t believe they handle the exceptions in the same manner. Since the API for the DAAB is different, it would fit into spring as 'just another' data access api with a corresponding db template (or DbHelper) implementation that performs exception translation into the common DAO exceptions. This provides great independence to your business logic layer.

All that being said, we are in the early stages of development all we have out there right now is IoC which by its very nature is non intrusive. We will take each step carefully and welcome your input!

Cheers,
Mark

[Tom Whitner]

As Choy says, there is no reason you can’t use some EL blocks in your code and have Spring wire up your applications.
I did not see the approach the EL is using to “wire-up” these blocks.

At the application level, it certainly seems reasonable to use Spring for wiring-up the blocks into the application. The real challenge, in my mind anyway, is in dealing with inter-block dependencies. For instance, if a security block requires logging. I am mainly in the business of designing blocks that my company needs that aren't part of EntLib. We want everything to play well together, and one model is better than two. It appears that the approach MS takes when block A requires block B is for block A to access a factory in block B directly. I believe this is akin to Service Location.

[Mark Pollack]

Hi,

As far as I can see if app block B depends on A, there is an assembly reference. This isn't service locator or IoC configuration, just normal 3rd party library resuse with interdependencies among assemblies. Spring would let you configure your application by instantiating classes from these libraries (or any other 3rd party libs), configuring their properties, and then linking them to other properties on your application objects. The app blocks don't make use of System.ComponentModel so even that type of configuration is not a possibility, nor should it be very likely. Please let me know if I am missing something here about how the app blocks reference each other.

Cheers,
Mark

[Tom Whitner]

At this point, we have only had access to preliminary SDK and user documentation, but what I've gleaned so far is that each block will contain one or more service providers. Each provider will include its interface, a factory (generic and configurable), and an implementation. I am assuming these would be packaged separately. When one component depends on another, the references would only be the interface and factory, but not the implementation. Since the factory is configurable, it can be re-configured to provide a different implementation if desired. I am likening this factory to a specialized service locator.

It makes sense that as a consumer of these blocks, one could configure Spring.NET to use the factories that EntLib provides, etc. However, because EntLib makes the factories configurable, you then have two configuration efforts. One to configure EntLib's factories and another to configure Spring.NET. Additionally, as mentioned earlier, blocks built by MS will access their factories directly, by-passing any opportunity for Spring.NET to get involved.

The biggest concern I have is for devlopers in my organization that will be producing blocks internally. Do they follow the EntLib model or the Spring.NET model when building their own blocks? I can see the benefits of Spring.NET, but I have to sell many other architects and developers that some additional complexity and possibly understanding two models is definitely worth it. Hence my persistence in quantifying the benefits of DI over SL.

So far, the best reason I perceive is allowing unit testing without configuration.

BTW, I really appreciate the discussion on this. This represents a major change in the way people think, and within a large organization, it takes an incredible amount of time and effort to alter the direction of movement.

Thanks,
- Tom

[Mark Pollack]

Hi,

It seems the question is more generic than the EntLib, which is how does Spring integrate with any 3rd party library that provide classes which follow the Abstract Factory design pattern. The approaches you take will largely be dictated by the details of how the abstract factory was implemented and what configuration options are available but Spring.NET already offers solutions for this situation that help. This is a very common issue in the Spring.Java world.

The use of 3rd party factory objects is accommodated for in Spring in two ways. First by using the factory-method attribute (if a static factory class) and the factory-object attribute in the case of using an instance of a factory. You can look at section 3.2.3.3 (http://www.springframework.net/doc/reference/objects.html#objects-factory-class) in the docs for some more information.

The second way is to create an implementation of the interface IFactoryObject that lets you handle more complex scenarios. These tend to be very simple implementations, less than 10 lines of code because they are more of an Adapter/Wrapper than anything else. If there is extensive configuration required by the 3rd party abstract factory, a reference to the config file, or whatever source, is all that is needed. This reference would simply be passed to the 3rd party library API. Spring.Java has many more examples of these than Spring.NET right now. Take a look at the JavaDoc for FactoryBean (http://www.springframework.org/docs/api/org/springframework/beans/factory/FactoryBean.html) to get an idea of the varieity. The first ones for Spring.NET are for AOP and also for remoting...but that is off topic. In as much as there are defacto-standard 3rd party libraries that people would like to use, we can incorporate them into the IoC container.

We are not suggesting to subsume all the configuration details of 3rd party libraries, just to absorb their particular creation mechanism into Spring. If you take hibernate or Quartz (timer) support in Spring.Java as an example, the configuration file can be external - as is often the case. In this case you of course need to be familiar with the mechanisms for configuring that library- that is simply the cost of doing business. However, the advantages of getting a reference to these objects within Spring's IoC container still remain.

In terms of following the 'EntLib' model or the Spring model for abstract factories...well it seems to me that Spring provides the mother of all abstract factories, you never need code one again - so why not use it and save the time/effort to write one for each 'Product' you need to create. The EntLib is not providing this generic abstract factory functionality for use with any set of interfaces and classes, just the ones they provide. So in terms of new development I don't see what there is to reuse from the EntLibs regarding object factories, but again, I maybe missing something here. BTW, this is another small reason why using Spring helps make a better designed app, developers are often lazy to implement an Abstract Factory over and over because of the coding involved (though nice IDEs make that less of an issue with code generation)

I still don't view it so much as a DI vs SL issue (wow - we sure have reduced the issue to a small acronym laden sound bite). You should appropriately pick and choose the times when to use each approach. I think you will see after trying it out that you can use DI/IoC most of the time, in particular for wiring up layers of your application. I've seen SL be preferred when more granular and dynamic grabbing of resources is needed. In the case of JMS (I know it a Java example) when you want to get reference to potentailly hundreds of Destination objects that have been registed in JNDI (aka service locator) at runtime, you wouldn't put that info in the config file, let the class go out and get the reference using JNDI at runtime. That is probably an extreme example however.

Hope this helps.

Cheers,
Mark

[Anonymous]

We are facing the decision of which metaphor to embrace: Spring.NET or Enterprise Library. EL is nowhere near as flexible as Spring.NET, but (1) it is simpler, (2) it has MS behind it, (3) it comes with other infrastructure functionality already implemented, ands (4) it is due to release by January.
Bear in mind that the patterns&practices stuff typically doesn't have the full 5+2 support cycle that official Microsoft products do, and that technically Avenade owns the IP (or at least part of it) for the EntLib stuff, which may make a difference to you or your company's lawyers.

If you're needing to start development now, I wouldn't wait, but if you can wait, it certainly doesn't hurt to do so until January (actually December) when the EntLib stuff comes out. We (the GAPP group) will probably be talking about EntLib at the next patterns&practices Summit, but that's probably not going to be until March sometime.

Ted Neward
http://www.neward.net/ted/weblog

Actually, in terms of the licensing, there will be no issues in using Enterprise Library (call off the lawyers! :D ). While Avanade is the originator of the IP, the licensing that goes along with Enterprise Library will clearly mimic those of the previous Microsoft Application Blocks and will not contain any new restrictions that should create any concern.

Sandy Khaund
http://blogs.msdn.com/sandyk/

[Mark Pollack]

Hi,

Just remembered there is another way to tell the IoC container to create classes that exposed by the abstract factory pattern, use the MethodInvokingFactoryObject to specify the target object, target method and arguments to that method. See Section 3.16.1 (http://www.springframework.net/doc/reference/objects.html#objects-methodfactory) in the docs for some more info.

Cheers,
Mark

[CyberPunk]

I know it's an old thread but Ent Lib is by now defunct... gone.

and IMHO... it was a pain to work with. I've got my fair bit of nightmares when running Ent Lib on production environments.

[kibbled_bits]

Good riddance. Is this official? Could you provide links?

Thanks

[Mark Pollack]

AFAIK, there will be EntLib 5..... where did you get this info?
Mark