If you define the collection as an Iesi.Collections.Generic.ISet, and initialize it with a Iesi.Collections.Generic.HashedSet, then the hbm will generate as a >set< tag, rather than a %gt;bag%lt;.

Only took me two days to figure that out. I love FNH, but their documentation could be a little more substantial. But it is open source!

Your reasons for using sets make sense. I’m trying to understand the Fluent convention stuff to figure out how to make “AsSet” the default.

#1 – I couldn’t say without seeing the mapping generated by FNH’s automap. I suspect that it has automapped this collection as a list, not a set. If that’s the case, I can’t tell you how to change that behavior. When it comes to my DB and my model, I’m a bit of a control freak, so I explicitly map everything. The FNH google group can provide better assistance.

#2 – We use sets for two reasons. First, the order of the sections is unimportant. Since, in a list, order is maintained (at least within the POCO), it can imply that order is important. More importantly, sets don’t allow duplicates. It makes no sense to have a section associated with its parent course multiple times, and can lead to bugs.

I have a “subscriber” class which is very simple, but contains a HasMany relationship to SubscriberContacts (e.g., email, cell phone, etc.) It is implemented just like Sections property in your Course object:

private ICollection _subscriberContacts = new HashSet();
public virtual ICollection SubscriberContacts { get { return _subscriberContacts; }
protected set { _subscriberContacts = value; } }

However, when I get to the Session.Save(newSub), NHibernate is throwing an InvalidCast exception saying it can’t cast a HashSet to a IList (which it can’t – HashSet is an ICollection, but not an IList).

My question is two fold – why is NHibernate trying to cast it to an IList, and why did we implement the collection with a HashSet as opposed to a List?

NHibernate is light-years ahead of the strongly-typed dataset approach. I know. I’ve been converted. At best, datasets will give you a bunch of DTOs to use in your own custom DAL with connections, transactions and DataAdapters flying all over. NH lets you just build your model and use it with an intelligent DAL already baked in.

Ayende’s blog is following a series by Davey Brion about building your own DAL and comparing that the NH features you get for free. It’s worth a read.

http://ayende.com/Blog/archive/2009/08/24/a-guide-into-orm-implementation-challenges-reasoning.aspx

http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-series/

I do have a question though. Back in Part 3, in the paragraph “8 Hours or 8 Minutes”, you implied that this approach is much easier than setting up your database. I’ve done a few applications using both MySql and MSSQL with Visual Studio and DataSets, in which I just go into the server explorer, define the tables, click Add New Item -> DataSet, and drag the tables from the server explorer onto the design surface, and presto, I have all my mappings. That seems an order of magnitude easier than this. What are the advantages to the NHibernate approach, even with Fluent mappings?

Specifically, on Problem #1, if I add Session.Save(Section1) and Session.Save(Section2) before the Session.Save(Course), then I’m getting a different exception from NHibernate saying “not-null property references a null or transient valueNStackExample.Section.Course” at the point I do the Session.Save(Section1). So it appears that you can’t save the Course until you have saved the Section, and you can’t save the Section until you have saved the Course! How do you solve that?

I tried to add 32-bit and 64-bit of System.Data.SQLite but it didn’t help.

Do you have any idea about this problem? Thanks