I have 2 main classes, both of them have various photos associated with them.

Here are my classes:
Plan, Community, Photo

Plans can have:
1 featured photo
0..* floorplans
0..* elevations
0..* regular photos
0..* gallery photos

Communities can have:
1 featured photo
1 plot map
1 area map
0..* regular photos
0..* gallery photos

Originally I had 1 join table for each class:
communities_photos_join
community_id
photo_id
joinType_id (gallery, featured, standard)

The problem here is that I can technically have 0..* featured photos, but that's not what I want. I want to avoid putting a featuredPhoto_id in the communities table because it needs to scale nicely if they do not select a featured photo (it should grab the next one in the list)

NHibernate is having problems with the current setup. It will load the photos correctly into my ILists, but saving does not work.

I am now debating having an association class to help handle some of this logic for me. The PhotoCollection class would have:
StandardPhotos
GalleryPhotos
FeaturedPhoto //would loop through standard to find the first candidate)
GetPhoto(type) //would get a specific photo, Area map, plot map, etc


Any thoughts on this? Most of the reason that I am changning my design is because NHibernate is not liking my initial setup, so keep that in mind.

well, i'mnot sure if you've considered this, it would require a change to your data model, but you could have an abstract "Photos" class with a subclass for each type of photo (Gallery, Featured, Standard). Then you could have a collection of Photos in your parent class (Plan, Community) that is a polymorphic collection of photo objects.

Your mapping file for the Photo class might look like:



your data model could reflect this polymorphism as well...

and your Plan class might look like:



I am using something like this for a company object that may or may not have a set of address object associated with it. Address is abstract and we have billing, mailing, etc.

HTH,

-devon[/code]

the problem is that it is a flawed design... an object cannot be more than 1 type... so your billing/shipping address model breaks because you need 2 objects there...

and also an object cannot change it's type during it's lifetime.... so your example of photo would break because 1 photo may be featured, and later on be a gallery image... or it could be both at the same time.