I was hoping to get some feedback on my approach to supporting strongly typed collections in a persistable class.

This example uses three tables: (1) Party, (2) PartyRole and (3) RoleType. PartyRole is a join table with a composite ID of PartyId and RoleTypeId. Here's the collection mapping:



The RolesUntyped property is implemented in the Party class as:



Note that RolesUntyped is a private property with a getter and a setter. There's a corresponding public property defined as:



Lastly, the corresponding member field is defined as:



This let's me leverage NHibernate for persistence while getting the advantages of strongly typed collection syntax. Let me know what you think.

This will probably cause inefficent set updates (whole collection will be deleted and re-created), unless it's mapped with inverse="true" (and contains entities).

Thanks, Sergey. The collection does contain entities, so it should just be copying references from one collection to the other. In this particular case, the assocation is one-way, so is it still useful to set inverse="true"?

Are their plans to provide native support for System.Collections.Generics in a future version of NHibernate? Wintellect's PowerCollections class library has generic-based implementations of ordered and unordered sets as well as other useful collection types.

http://www.wintellect.com/powercollections/

Hi!
Recently there has been a discussion in the mailing list where developers shared their ideas about .net 2.0 especially about supporting generics. One idea was that NHibernate could provide a PersistentCollectionFactory. Is this still under consideration?

thomas

It is, and probably will be under consideration for a long time. We are not yet brave enough to diverge much from the original Hibernate code and don't have much time. So unless somebody thinks up a solution, implements it, and sends us a patch (with tests!), it will stay unsolved for a long time :-(

Hi Jim

Have you experimented more with this? Anyone else?

We to have tried doing this, and we have several approaches. On which is almost exactly like yours.

The problem with this approach is that it will not work with lazy load, because the loop through the untyped collection will cause the collection to be fetched from the database.

Therefore we tried with something like this:



Does anyone know if it is possible to cast a IList like the NHibernate Bag to a Generic list, or will this always fail? Please notice that the above code compiles.

Thomas

The issue with casting an IList<T> to an IList is that IList<T> does not derive from IList. However, IEnumerable<T> DOES inherit from IEnumerable, which means in the case of IEnumerable<T>, casting back to IEnumerable IS possible - not that that helps us much here.

One solution you could try if you want to take advantage of generics in .NET 2.0 before the NHibernate code is updated, is to create a ListAdapter<T> class, which accepts an IList in its constructor and provides a type-safe wrapper around the IList implementation passed to its constructor.

You would then have one of your private member fields typed as IList (which you would point NHibernate at using the "field" access strategy), and another private member field typed as ListAdapter<T> which would be publicly available via a getter/setter.

I imagine the private ListAdapter<T> member would need to be lazy initialized when the getter is accessed. It could not be initialized in the constructor as NHibernate would not have had an opportunity to set the private IList member it wraps at this point.

I'm now using Wintellect's PowerCollections to solve the problem. I declare a member as NHibernate.Collection.Set then cast it to a typed ICollection, e.g.:



Note that the resulting collection is read-only.

I did something very similar to the code in the first post for a bag collection, but found my version didn't work...



List<Category> satisfies IList, so I can just return _categories to NHibernate as is. (This turned out to be a crucial difference... I was returning my actual collection to NHibernate instead of a copy like the code in the first post did.)

The problem arose from the documented fact that NHibernate replaces CategoryNHibernate with its own collection class during a save or update, in this case NHibernate.Collection.Bag. What I didn't know was this was actually a wrapper around the collection class I returned to NHibernate. So when I called _categories.Clear(), I was actually clearing out value (NHibernate.Collection.Bag) as well, and deleting all my categories... (The foreach loop never found anything in value to add.)

Note, this only happened in a save or update -- the retrieval of the object from the datastore works just fine, since value (NHibernate.Collection.Bag) in that case is not a wrapper but rather a new collection altogether.

If you want to do something similar, for bag at least, this modification solves the problem...



Or you can do what the code in the first post did and return a copy of the collection to NHibernate...

Try this:

http://www.ayende.com/projects/nhiberna ... erics.aspx

It'll let you use generic collections (and some other goodies)