Update on Spring.net/nHibernate Integration

[ivolved]

So here it is a few weeks after my initial post expressing interest in integrating Spring.net with nHibernate. And I have a few findings to communicate.

First, two more like minded developers have expressed interest in working on this integration project with me. Seeing that everyone is trying to get ten million things done before the end of the year, I have delayed starting on actual working on the integration until the new year. But I did learn something as I tried to figure why developing Winforms with nHibernate is such a paradigm shift from developing Web Apps with (n)Hibernate.

Winforms (and the new ASP.Net 2.0 webforms) really shine when it comes to Data Aware components. While .Net 2.0 does support generating Datasets and DataAdapters from Domain Objects...wouldn't it be better if nHibernate supported that directly? We already have mapping files that create objects from DataSets. It can't be very difficult to return the Dataset back to the user.

Essentially, where I'm going with this is that I'm going to implement a nHibernate .Net Data Provider (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconimplementingnetdataprovider.asp?frame=true). Of course if I had paid attention earlier when Mark made a suggestion (http://forum.springframework.net/viewtopic.php?t=225)
In terms of DataSource like abstractions, I've been playing a bit with making a new AdoTemplate. It seems to me the way to go is along the lines of the DbProviderFactory class in ADO.NET 2.0. I would have been on this trail a lot sooner.

I definitely think that the general AdoTemplate in Spring.Net should be based on around the Data Provider. Or even around the DAAB...however, I'd prefer the code to not rely on a framework that isn't standard to .Net.

So, to make a long story short. I have a general direction that I'm taking for integrating nHibernate with Spring.Net. I think that a similar approach should be taken for bringing any ORM framework into Spring.Net wrap it up as a Data Provider.

[Mark Pollack]

Hi,

Good to hear back from you.

Hmm actually I didn't think about a data provider approach for NHibernate...I'll have to think about that - it doesn't sound natural to me.

The DataProvider stuff for ADO is a natural fit because it goes a long way to allowing one to write provider independent code. The DataProvider lets you create each key element of the the ado.net class hierarchy independently in a provider independent manner. I started along this route if you look in cvs...though it isn't complete by any means. There still are gaps in the ado.net 2.0 provider model from what I can tell in terms of writing truely provider independent code - this is the result of having strongly typed IDbParameter classes and each vendor implementation has unique properties. There seems to be a basic trade off here in terms of type safety and portability. (Java gets around this by passing ints and strings around instead of types) I plan to write a IDbCommandData class that encapsulates all the necessary request/response data for an ado command, with at least the same richness in options for database parameters as in ado.net 2.0. It took me a while to work that out but I think I ready to commit code again to IAdoTemplate that uses this abstraction, not to mention other goodies :).

Anyway, w.r.t. to hibernate integration, I think the same template/transactionManager approach is the way to go. In the case of hibernate it should actually be easier than with ado.net since there isn't the throny issue of "provider independence" A HibernateTemplate class with the first method being a session callback (and/or delegate) would go along way. The second step would the transaction manager. The rest is just building on top of that. Maybe you can explain more what you mean in terms of the provider approach regarding hibernate integration?

Cheers,
Mark

[Aleks Seovic]

I agree with Mark -- it seems very unnatural to convert rich object model that NHibernate gives you back to a generic DataSet for display purposes.

AFAIK, you can bind controls to objects in .NET 2.0 just as easy as you can bind them to a DataSets, so I really don't see a need for this. Also, if there are problems with the binding, it is the binding we should be fixing, not changing the data model to work around the issues.

Later,

Aleks

[ivolved]

I agree with Mark -- it seems very unnatural to convert rich object model that NHibernate gives you back to a generic DataSet for display purposes.

I think that it's perfectly natural given the .Net environment. There is a lot of UI functionality that comes for free by using datasets. Use the dataset for display purposes and nHibernate's domain model for business logic and the like.

I've already mentioned the project on the nHibernate discussion boards and got a nod of approval as this was something already on their radar to implement.

AFAIK, you can bind controls to objects in .NET 2.0 just as easy as you can bind them to a DataSets, so I really don't see a need for this. Also, if there are problems with the binding, it is the binding we should be fixing, not changing the data model to work around the issues.

Later,

Aleks

I understand that .Net 2.0 supports Object binding. However, 1.1 doesn't have that support right now. Wrapping Hibernate and the other O/RMs in DataProvider is the fastest way to bring that support to .Net 1.1

Also there is nothing that says we can't implement DataProvider and extend it. That way our users get the best of both worlds. A powerful O/RM when they need it and easy data presentation when they don't.

I think all of our DataTemplate classes should start by implementing DataProvider (or at the very least DataAdapter). Of course there can be other Interfaces presented by the DataTemplate...but DataAdapter provides a good starting point.

[Aleks Seovic]

I just don't see the purpose -- if I want DataSet I will use upcoming Spring.NET AdoTemplate support to execute the query I want and get the results directly as a dataset.

There is absolutely no need to use NHibernate in this case -- it is simply an unnecessary overhead.

- Aleks

[Mark Pollack]

Hi,

I afraid I'm still not seeing it. Leaving aside databinding and datasets (I am not an anti-DataSet object bigot) but the provider model for ADO.NET is all about creating objects in the ADO.NET hierarchy. What meaning is there to implementing the methods on DbProviderFactory (http://msdn2.microsoft.com/en-us/library/system.data.common.dbproviderfactory.aspx) for NHibernate?

For example, CreateCommand, CreateConnection etc... return objects in the ADO.NET hierarchy not relelated at all the NHibernate way of doing data access. We can provide some support for converting business objects to DataSets, so in that case we will need to provide a DataAdapter, but that would not sit in the same class as our IDbProviderFactory.

As in Spring.Java The various template classes can inherit from some "Accessor" class that provides the means for the template to its job, but that Accessor is different for each data provider. Did you take a look at the Spring.Java hibernate template support yet?

Hope we can come to some common understanding. An IM session maybe more appropriate than email/forums. Speak to you soon.

Cheers,
Mark


[/url]

[ivolved]

Sorry for the silence over the weekend.

Basically what I was trying to say is that if we are looking for a generic interface for Spring to use for integrating O/RM tools into Spring, DBProvider is an option.

For instance nHibernate already supports the idea of connections (sessions), transactions, and commands.

Again, there isn't any reason why the Template can't support using the underlying tool directly, but I definitely that implementing dbproviders around it might be a direction to consider seeing that it's the lingua franca of .Net Framework data access.

[rpark68]

We are using both Spring and NHibernate, so of course I'm interested in be connected with this thread. Any new news?

WRT the dataset discussion, I would consider it a bad design to tightly couple your UI and the DB via a direct query and the ado wrapper. The ADO wrapper is a good thing (and we should use it in some spots), but it should be down in a DAO... IMO.

That kind of logic is partially why we're using nhibernate and we have been toying with the link from data grids to objects. Looks pretty good, but we haven't had an implementation need yet.

My specific interest in the NHibernate wrapper is how's it going to work? Where do we set the hbm.xml assemblies? How does the session get opened and closed?

Currently we have some web services and a web app where our business object will open the session, then the DAOs will get the session from a singleton (maintained by Spring), and lastly the biz object will close the session before the reply page is sent.

Thanks.

.rob.

[Mark Pollack]

Hi,
The code is sitting in the sandbox. You will have to pull it down from CVS or I believe you can also get it from the daily builds on our web site.

You can specify the hbm.xml assemblies using the following declaration

<object id="SessionFactory" type="Spring.Data.Orm.NHibernate.LocalSessionFactoryObje ct, Spring.Data.Orm.NHibernate">
<property name="DbProvider" ref="DbProvider"/>
<property name="MappingAssemblies">
<list>
<value>Spring.Data.Orm.NHibernate.Integration.Tests</value>
</list>
</property>
<property name="HibernateProperties">
<dictionary>

<entry key="hibernate.connection.provider"
value="NHibernate.Connection.DriverConnectionProvider"/>

<entry key="hibernate.dialect"
value="NHibernate.Dialect.MsSql2000Dialect"/>

<entry key="hibernate.connection.driver_class"
value="NHibernate.Driver.SqlClientDriver"/>

</dictionary>
</property>

</object>


I have not added the other input sources for mapping files yet - though that is easy work. What I know is not yet implemented is providing a session.Close() ignoring proxy for ISession (you probably don't need to worry about that for now - just don't call close in the callback function - see below), setting of isolation level, and the use of AdoTemplate within the same transaction as hibernate. Otherwise it is feature complete with the Spring.Java version, afaik.

The general approach with HibernateTemplate is that you do not need to worry about calling session open and close - that is managed by the template. Exception handling is also managed by the template. What you provide is an implementation of a callback interface specifying the 'meat' of what you want to do with a hibernate session.

object Execute(IHibernateCallback action);

There is also a delegate version. The callback provides you with a "managed" ISession instance, don't worry about calling open/close or doing any exception handling. For many common scenarios you will not even need to use the callback as there are many convenience methods on HibernateTemplate that make the most common hibernate operations a simple one liner. You can take a look in the directory sandbox\test\Spring\Spring.Data.Orm.NHibernate.Int egration.Tests for some sample code.

However, you must demarcate your transactions using a hibernate transaction manager in combination with a source of the transaction metadata. The source of the transaction metadata in this case would commonly be a Transaction attribute on the DAO class methods. The boilerplate spring xml for this would be


<object id="transactionInterceptor"
type="Spring.Transaction.Interceptor.TransactionIntercep tor, Spring.Data">

<property name="TransactionManager" ref="hibernateTransactionManager"/>

<property name="TransactionAttributeSource">
<object type="Spring.Transaction.Interceptor.AttributesTransacti onAttributeSource, Spring.Data"/>
</property>

</object>




<object id="testObjectDaoViaTxAttributes"
type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">

<property name="Target" ref="NHTestObjectDao"/>

<property name="ProxyInterfaces">
<value>Spring.Data.Orm.NHibernate.ITestObjectDao</value>
</property>

<property name="InterceptorNames">
<value>transactionInterceptor</value>
</property>

</object>

with the attribute in the DAO code being

[Transaction()]
public void Create(TestObject to)
{
HibernateTemplate.Save(to);
}


In this case I specify exactly which interface to wrap in a transaction, by default all interfaces on the object would be transactional. You can infer the rest of the config from looking at templateTests.xml in the sandbox/test area.

I did not implement an open-session-in-view functionality for use with ASP.NET I think this would only be an issue if your asp.net code is going to navigate through the object retrieved by hibernate and come across a collection property of your business object that was not loaded by hibernate, say due to a lazy-load setting. If you have fully populated your business object's graph then you should be able to use the functionality that is currently in the sandbox without any changes.

Let me know how it goes. You can also read up on the approach to hibernate in Spring.Java. The Spring.NET version follows this and the documentation is fairly portable in that regard.

Cheers,
Mark

[rpark68]

This all looks very cool. Much more elegant than what we have existing. Hopefully, we'll get to playing around with it this month.

Question: do you have a recommendation for setting the connection string at runtime? I think this is pretty common, but in our case our prod connection string is different than our local sandbox or test environments. So this means I can't include it in our embedded spring context. Currently, we set it in on a SessionFactory object from global.asax at web site startup where the connection string is defined in the web.config.

Should something like that still work?
Is there a more elegant solution?

Thanks.

.rob.park.

[Aleks Seovic]

Hi Rob,

I believe the best practice is to use standard configuration file to store connection information:


<configuration>
<configSections>
...
<section name="databaseSettings" type="System.Configuration.NameValueSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</configSections>

<databaseSettings>
<add key="db.server" value="(local)" />
<add key="db.user" value="sa" />
<add key="db.password" value="" />
<add key="db.schema" value="SpringAir" />
</databaseSettings>

...

</configuration>


It doesn't really matter if you separate each parameters as in the example above or if you simply provide a single 'db.connectionString' property. You also don't necessarily need separate <databaseSettings> section -- you could also put your settings within the standard <appSettings> config section. You need to make these two decision based on what you think will work best under your specific circumstances.

Once you have connection string info in the main .NET config file, you can reference them from your Spring config file like this:



<object type="Spring.Objects.Factory.Config.PropertyPlaceholderC onfigurer, Spring.Core">
<property name="ConfigSections" value="databaseSettings"/>
</object>


<object id="MyBaseDao" abstract="true">
<property name="ConnectionString" value="Server=${db.server};Integrated Security=no;User ID=${db.user};PWD=${db.password};initial catalog=${db.schema};"/>
</object>


PropertyPlaceholderConfigurer is a post-processor that will replace values in your object definition with the values from the <databaseSettings> config section, in this case.

HTH,

Aleks

[rpark68]

Whoa... very cool.
Thanks for the info on getting from web.config to spring. :-)

.rob.

[Billy]

Mark, Aleks:

NHibernate's ability to lazily load collections within ASP.NET is a huge bonus. I'd like to add the capabilities within Spring.Data.Orm.NHibernate to facilitate this but would like your advice before doing so. What is your impression of the following approach:

1) Create a new class to wrap the result of config.BuildSessionFactory():
Data.Orm.NHibernate.WebSessionFactory : ISessionFactory
This wrapper would override OpenSession with a method to look for a session on the current HttpContext and return it if found. Otherwise, it creates a new session and binds it to the HttpContext. I'd also have to make sure Close is called within the OnRequestEnd event within Global.asax.

2) Create a new class to create the WebSessionFactory:
Data.Orm.NHibernate.WebSessionFactoryObject : IFactoryObject, IInitializingObject, IDisposable
This would work similar to LocalSessionFactoryObject, but it would return a WebSessionFactory.

The drawbacks that I see are:
- duplicated code between LocalSessionFactoryObject and WebSessionFactoryObject
- having to call Close within Global.asax

Thoughts, suggestions?

Billy

[Aleks Seovic]

I don't have much experience with NHibernate, but based on what I know it sounds like a reasonable approach.

The only thing I would change is to use an IHttpModule instead of global.asax to close the session at the end of a request -- it is a much cleaner approach than to ask users to copy&paste a piece of code into global.asax.

Later,

Aleks

[Mark Pollack]

Hi Billy,

I think what you are looking for would be an adoptation of the "Open Session In View" approach described on the hibernate site (http://www.hibernate.org/43.html). Spring.Java's answer to this is to use a custom web filter OpenSessionInViewFilter (http://www.springframework.org/docs/api/org/springframework/orm/hibernate/support/OpenSessionInViewFilter.html). I believe this would map onto a custom IHttpModule. On the .NET side we should see if we can make a simple "transliteration" of the OverSessionInViewFilter class. Any approach should bind the session to the current thread and not store it in the HttpContext since HibernateTemplate is looking for sessions in thread local storage.

I'll also read over the links on this page, NHibernate with ASPX (http://www.hibernate.org/363.html) to look for similarites in other approaches to integration.

Cheers,
Mark

[Billy]

Thanks for the heads up concerning HibernateTemplate. I should have some time early next week to take a stab at it...I'll keep you posted.

Billy

[ivolved]

After a bit more experience with NHibernate and winforms. I have been developing a set of classes based on the Command Pattern that encapsulate various NHibernate Actions.

I then began to think how this framework would fit into Spring and come to the forum to post an update (yes I know almost three months later). Lo and behold I find that I have developed in parallel something similar to the NHibernateTemplate that Mark mentioned.

Here's the thing. My Action classes rely heavily on .Net generics. (And thus .Net 2.0 framework).

The base class handles Session and Transaction management as well as Exception handling. The sub-classes implement common actions in a generic manner, such as saving/updating, loading by identity, loading by unique key, selecting all or a specified number of objects that match a value on a given field. The action classes can also attempt to rerun on error (after rolling back a transaction)

I am also creating general business logic actions (actually the data actions derive from the bl actions) that provide debug logging, exception handling, and the like. It's not a lightweight framework at all currently because I'm not using delegates or declarative wrapping of functions.

Honestly, it looks like my classes replicate the code already done by the Spring.Net team. And they wouldn't fit in with Spring.Net until there is a .net 2.0 version anyway. I just wanted to let everyone know what my progress was trying to fit Hibernate (and the concerns with Lazy Loading/Session Management) into the world of .Net best practices.

Curiously, they do fit in well with the Composite UI App Block. The IWorkItem classes map very well with my Action classes. Also looking closely at the CAB, I see a lot of overlap between what it provides and what Spring.Net provides...EXCEPT for the Winform/UI tools. With the LINQ project in full swing, I'm concerned about the appeal that these two great tools to MS Development new comers can possibly provide over NHibernate and Spring.Net.

I know there's enough for Spring.Net and NHibernate to coexist with the CAB and LINQ. I'd like to hear what are the thoughts of the Spring.Net team?[/code]

[Mark Pollack]

Hiya,

Good to hear from you again. I’m interested to see what you have done as we will eventually venture into the winform UI space and an action framework is a great feature to have in a ui-framework. I’m not surprised to hear that your action framework fits well into a UI framework, i.e. CAB or otherwise. However, I don’t think that an action framework is the basis to create a data access framework. In this regard I believe that the feature set and design of Spring’s data access functionality that is currently in CVS is more appropriate and I'm open to comments/criticsm in that regard. Spring’s approach to data access is very different from anything else out there in that it is providing a consistent approach to data access across various data access technologies with non-invasive declarative transaction management being a key feature. So far this support applies to ado.net, nhibernate, and ibatis but that is not a closed set. The design of the data access framework provides a generic abstraction to transaction management and we will support whatever other data access technologies users demand where we feel we can add value. That maybe ObjectSpaces/LINQ or another commercial product not from MS.

There is no reason that your action framework and Spring’s data access framework can’t can’t co-exist. One can use Spring IoC/DI to configure business actions with a Hibernate template if they require such functionality. I’ve integrated Spring with the previous UI application blocks and I don’t see a reason why we won’t be able to use Spring to wire up a CAB application and/or your action framework. FYI, we have finished our initial support for .NET 2.0, you can get it from CVS. It would be good to use your action framework as a test-case to see what gaps we have. Also, the retry ability you mention, wouldn’t that better be left as a strategy to apply inside an exception handling layer instead of ‘baked’ into the core of the class functionality?

I don’t see much overlap with CAB and Spring.NET. If you cast that net larger, to include the enterprise libraries there is more overlap, but even then the core value propositions Spring offers, dependency injection, AOP, and how they apply to a PONO programming model for business services (i.e. remoting, web services, system-component enterprise services) show a huge gap between the two. (The current DI support in CAB misses the mark in the key area of non-invasiveness imho…but that doesn’t mean they won’t improve in future releases.) Other great features like the web framework, validation framework, and object navigation library don’t have any counterpart in CAB. While where at it, it is worth noting that some companies can’t use the EntLib libraries because they do not allow redistribution outside the organization, a big deal for third party vendors. I don’t know the case for the CAB license.

I’ll be the first to acknowledge that I don’t know much at all about LINQ but in terms of the here and now it is too new for many enterprises to consider going into production with. For that matter many companies are going to wait a while to shift to .NET 2.0, a naturally conservative approach. That is not to say we are going to ignore it – we will certainly look to see if there is anyway that Spring may add value in same mold as done in the past.

Well, I’ll get off my soapbox now. As you say, there is more than enough room for all these libraries as there are a lot of developers out there with varying needs. There is of course a natural tendency in the .NET community to first look to Microsoft and then to open source but hopefully that will change – and it would be a change for the better.

[rpark68]

Just wanted to extend a mention that we are fully committed to .NET 2.0 and would love to see both Spring and NHibernate have better support for generics.

.rob.

[Billy]

Rob,

If you haven't yet seen it, check out Ayende @ Rahien's support for NHibernate Generics (http://www.ayende.com/projects/nhibernate-query-analyzer/generics.aspx). I've been developing with his very easy-to-use assembly with great success.

Billy

[rpark68]

We did try that out about 2 months ago, but we had some difficulties that caused us to pull it out. I don't remember the issues at this point. Maybe we'll give it a try again now that we have a better handle on what we're doing with NHibernate in the first place.

Thanks.

.rob.

[ivolved]

We did try that out about 2 months ago, but we had some difficulties that caused us to pull it out. I don't remember the issues at this point. Maybe we'll give it a try again now that we have a better handle on what we're doing with NHibernate in the first place.

Thanks.

.rob.

Rob,
My action classes take advantage of .Net 2.0 generics but as I said before they aren't ready for public consumption just yet.

[ivolved]

...However, I don’t think that an action framework is the basis to create a data access framework. In this regard I believe that the feature set and design of Spring’s data access functionality that is currently in CVS is more appropriate and I'm open to comments/criticsm in that regard. Spring’s approach to data access is very different from anything else out there in that it is providing a consistent approach to data access across various data access technologies with non-invasive declarative transaction management being a key feature.

Actually, the Command pattern only arose from the lack of Closures (methods as objects) within many languages. I didn't even THINK of using delegates for my framework but they are essentially two ways of tackling the same problem, wrapping a function with generic code. With the 2.0 framework we can even do anonymous delegates, meaning you can define the delegate anonymously within a function instead of having to declare a separate function JUST to be used as a delegate. In addition, your anonymous delegate can be declared generically (meaning that even if the delegate assigned to a delegate that takes parameters, the inline delegate doesn't have to take any). But you are right, using delegates is defiinitely less invasive than action classes.


There is no reason that your action framework and Spring’s data access framework can’t can’t co-exist. One can use Spring IoC/DI to configure business actions with a Hibernate template if they require such functionality. I’ve integrated Spring with the previous UI application blocks and I don’t see a reason why we won’t be able to use Spring to wire up a CAB application and/or your action framework. FYI, we have finished our initial support for .NET 2.0, you can get it from CVS. It would be good to use your action framework as a test-case to see what gaps we have. Also, the retry ability you mention, wouldn’t that better be left as a strategy to apply inside an exception handling layer instead of ‘baked’ into the core of the class functionality?


I'm sure with further refactoring that I would have separated the exception handling out from the core data action class. Like I said, this framework is definitely a work in progress. I just saw that I had a lot of code that I was retyping or cutting and pasting and came up with the action classes as a way to generalize that code. It's basically a combination of the Command Pattern and the Abstract Template Pattern.

The framework is currently locked as is because I developed it for a project I'm working on...but I will definitely be revisiting it with your critiques in mind.


I don’t see much overlap with CAB and Spring.NET. If you cast that net larger, to include the enterprise libraries there is more overlap, but even then the core value propositions Spring offers, dependency injection, AOP, and how they apply to a PONO programming model for business services (i.e. remoting, web services, system-component enterprise services) show a huge gap between the two. (The current DI support in CAB misses the mark in the key area of non-invasiveness imho…but that doesn’t mean they won’t improve in future releases.) Other great features like the web framework, validation framework, and object navigation library don’t have any counterpart in CAB. While where at it, it is worth noting that some companies can’t use the EntLib libraries because they do not allow redistribution outside the organization, a big deal for third party vendors. I don’t know the case for the CAB license.


I didn't know for sure what kind of overlap there was between spring and the CAB but I did see that they had DI within it and was wondering how that impacted Spring.net. You definitely answered that question well.


I’ll be the first to acknowledge that I don’t know much at all about LINQ but in terms of the here and now it is too new for many enterprises to consider going into production with. For that matter many companies are going to wait a while to shift to .NET 2.0, a naturally conservative approach. That is not to say we are going to ignore it – we will certainly look to see if there is anyway that Spring may add value in same mold as done in the past.

From what I understand about LINQ is that it brings native support of relational queries to .Net. This means that your select clauses are validated by the compiler rather than at runtime. Just like NHibernate you can do a select from myClass o where myProperty="foo" except you'd have full intellisense and compiler support of this construct.


Well, I’ll get off my soapbox now. As you say, there is more than enough room for all these libraries as there are a lot of developers out there with varying needs. There is of course a natural tendency in the .NET community to first look to Microsoft and then to open source but hopefully that will change – and it would be a change for the better.

Actually I appreciate that Microsoft appears to be more in tune with their development community than Sun has been so far with .Net. Take Generics...it took 10 years and six releases before Sun dropped in a hack to support generics, whereas we have native Generics in .net after three releases and four years. There is a significant difference between .Net generics and Java generics. Reflecting on a generic in Java at runtime, you will not be able to determine what the type parameter is (It will look like a standard, non-generic Collection of objects). Do the same in .Net and you will see an IList of int or what have you.

But I also appreciate the contributions of the Open Source community to .Net developers at large. I don't know what I would have done without NHibernate and open source code generators to help me map my 20+ tables. Yes I do...I'd still be writing stored procedures and hand coding mappers for my project instead of finishing off the UI today.

[Mark Pollack]

Hi,

Yea, no doubt that 2.0 will make the API nicer with anonymous delgates. Also AdoTemplate will be improved with better typed return values. I plan on a later release having more 2.0 friendly versions of the data access api's. I will certainly take a look at the previously mentioned link for nhibernate and generics.

Yea, I think that .NET has been more progessive/agressive in many regards w.r.t to Java, not to get into a full blown comparison. I guess my point there was in another direction that I don't wanna get into now.

Thanks for everyones comments...

Cheers,
Mark

[Billy]

I should have some time early next week to take a stab at it...I'll keep you posted.

Well, three weeks later and I finally put something "official" together concerning the integration of NHibernate with ASP.NET. I haven't yet integrated it into my local Spring .NET code because it departs a bit from the current setup - it relies on HttpContext.Current.Items for storing the current session. The article and demo code can be found at TheCodeProject.com (http://www.codeproject.com/useritems/NHibernateBestPractices.asp).

If any of you have time, I would love feedback as to if my approach to NHibernate session management within ASP.NET would be an appropriate fit for Spring .NET.

Billy