Hello,

Normally I would implement IUserCollectionType but I am a little confused in this instance.

I have a class that derives from List<SomeType> and implements IList<SomeType>. Doesn't NHibernate find that my class I am attempting to map in a <bag> implements IList<SomeType> and can safely cast it as PersistentGenericBag?

I wouldn't imagine I would have to create an implementation of IUserCollectionType if I am doing a simple inheritance from known collection types.

Can anyone shed some light for me? It would be greatly appreciated!

Thank you

Sean

bump.

this can't be that difficult can it? I know there has to be an easy solution here that I am missing

Actually, this topic is not that simple. What are you really trying to accomplish with your own collection?

NHibernate doesn't "cast" your collection to a PersistentGenericBag, it instead wraps your collection as a PersistentGenericBag (casting would be impossible after all). So what you could do is whenever you create your object you would be using your custom collection type (must be referenced as an IList<> though). However, once NHibernate creates the object, it will use its own collection type.

Really, you need to go through a lot more steps if you want to use your own collections. Go back to reading about the IUserCollectionType.

I see. i was under the impression that PersistentGenericBag implemented IList<Type> as well.

I just keep running into scenarios where i need to add constraints on collections and it would be easier to derive List, override add and remove and be done, but if I need to implement IUserCollectionType then I will just create a new class and encapsulate the collection and logic there. Then associate it in the mapping file as a component class. This would work.

Thank you for your help!

Sean

It does implement IList<Type> but that doesn't mean it also inherits from your custom collection. You can't cast between two types just because they both implement the same interface. However, you could reference both types by using the same interface. Does that make sense?

I think so.

What do you mean by that?

I'm still interested in an answer to the question jchapman asked... What are you really trying to accomplish with your own collection?

I want to make a custom collection to define constraints for adding/removing items to the list.

For instance when you add an item to the list, if the collection is bidirectional I wire up the inverse end of the collection.

Or some other domain logic that needs to be applied before adding/deleting collection items.

I do exactly that a lot, but I never even considered implementing my own custom collection to do it.

Why can't you do something like this?

To implement your own CollectionType see the following articles:
http://analog-man.blogspot.com/2007/01/bridge-gap-between-your-nhibernate.html
http://damon.agilefactor.com/2007/07/nhibernate-custom-collections.html

@dkode,

I have a simpler solution for you: http://forum.hibernate.org/viewtopic.php?t=981926 .

@PandaWood,

Your example works, but a drawback is that "administrative" duties for managing have now moved to the parent object. If you want to use a similar collection from another object, you may run into duplications of the "administrative" duties on the other parent object as well. The collection itself, in most cases, should be managing these types of responsibilities itself. This keeps the parent objects to the single responsibility principle and promotes better reuse throughout the application.

Billy McCafferty

I wouldn't be overly sure about your drawback. In the sample I was taking this from, it was 'entirely appropriate' for the Parent to be managing a particular duty. As it was the only one who could perform it.
If your domain has logical dependencies on parents, then that's what there should be. There's no good in keeping your code-model more pure than your domain-model.

It's a possible drawback but not necessarily.

I certainly can't disagree with putting the word "possible" in front of it. Every scenario demands its own solution.

Billy McCafferty