I could do the same thing with NHibernate, but I’m not going to introduce a new non-Microsoft dependency to a project someone else will most likely end up maintaining if it doesn’t gain me anything, that’s like asking someone to learn calculus before I let them balance my checkbook — if learning calculus meant I didn’t have to balance the checkbook by hand, it might be worth it…

I’m not content with the end result because the business objects aren’t POCO (Plain Old CLR Objects) now (I could make POCO objects, but taking the persistence out means I loose lazy loading).

Also, I had to leave a few EntitySet collection properties exposed, because LINQ goes into a tail spin during my unit-tests if I try to actually claim IEnumerable on the Factor objects … I had never seen the Operation could destabilize the runtime error before!

When you start trading design for cohesion with a tool you are in essence trying to fit the proverbial square peg in a round hole. Your instincts told you stay clear (you decided to bite the bullet) – listen to your gut.

You should check out this article – the first person who responded to it (Brian Towers) sums up ORM very elegantly.

http://www.simple-talk.com/community/blogs/tony_davis/archive/2008/08/06/66526.aspx

I’m digging around the Java docs now, they seem more complete than the .Net ones …

“foreach(Level lev in aFactorVariable){...}” You may still do this, implementing IEnumerable on you Factor.

Second,
You seem to have unclear/unexpressed concepts. You have a pool of Factors with levels as your basis. And you have instances of those for an experiment/model. Currently you seem to mix these to. I would go and decouple those: Have Factor->Levels and Have Model->Specific Factors->Specific Levels (as copies).

There may be possibilities, to map a Factor inbetween Model and assigned Levels (through embedded components, maps, ...). I suggest reading the NH / Hibernate.Java Doc+Samples on these topics. However, this is going to be a complex mapping and still, you ´would have concepts you should make more explicit (in the sense of DDD).

-Sebastian

Second issue, you need a set of many to many.
You can ask a specific question in teh mailing list