James,
in OO terms, I can have:
public IList<Rate> HourlyRate { get; set;}
public IList<Rate> OtherRates { get; set; }
and this works perfectly well. Rate is a type and with a colletcion, I
specify a set (or a list in this case) of entities (or values if we'd
be talking about value object). Indeed, when talking about value
objects, the proper way would be to model Rate as a struct, but I was
unable to serialize it as such (I got error that NHibernate has a non-
mapped association). Event though the Rate struct was inside the
namespace that I configured for Automapping.
Regards,
Miha.
ps: and in most cases, when we model our domain, we have to (IMHO)
think about persistence (and ususally that means tables) as well -
unless a domain is a fairly trivial one.
On Aug 19, 9:36 pm, James Gregory <jagregory....@gmail.com> wrote:
> Why are the classes a workaround? Are you designing a domain model or a
> database?
--
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibern...@googlegroups.com.
To unsubscribe from this group, send email to
fluent-nhibernate+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en.
