Yeah I agree...that is why I need a collection of IMaterialsTests on
Sample and not a many-to-one on the IMaterialsTest=>Sample. I may be
missing some other insight in the domain here...
On Nov 19, 3:30 am, "Gabriel Schenker" <[EMAIL PROTECTED]> wrote:
> In DDD the domain model is all that counts. The database is only an
> implementation detail. We should not let ourselves limit by the database in
> my opinion. Restrictions (especially if some business logic is behind them)
> have to be enforced by the domain. I know, this is an extreme position but
> it makes life much easier :)
>
> On Tue, Nov 18, 2008 at 4:44 PM, Mike Nichols <[EMAIL PROTECTED]>wrote:
>
>
>
> > Thanks for the input Gabriel.
> > I am afraid your suggestion might be the most straightfoward way to do
> > this without making my domain object depend on an IREpository.
> > The problem is enforcing some rules, notably 'only one test of type T
> > may be 'Approved within an Sample'' in a straightforward manner.
> > Putting this info on the test instead of the sample pushes me into
> > introducing some kind of ITestApprovalService with calls like
> > 'IsApproved' for each time I view the test. I was trying to see if I
> > could keep this directly on the Sample entity so I could have this:
>
> > SampleTest{
> > IsApproved{get;}
> > IMaterialsTest {get;}
> > ...other info
> > }
>
> > Sample {
> > ICollection<SampleTest> {get;}
> > Approve(IMaterialsTest test);
> > }
>
> > But since IMaterialsTest has alot of different implementations and is
> > not mapped directly in NHib, this can not be easily modeled
> > relationally.
>
> > On Nov 17, 11:36 pm, "Gabriel Schenker" <[EMAIL PROTECTED]> wrote:
> > > why not introduce an entity TestSample which references the entity
> > Sample?
> > > IMaterialsTest then holds a collection of TestSample
>
> > > On Mon, Nov 17, 2008 at 7:28 PM, Mike Nichols <[EMAIL PROTECTED]
> > >wrote:
>
> > > > I have this model:
>
> > > > interface IMaterialsTest { Sample{get;set;} }
> > > > abstract class Sample { ... }
>
> > > > Originally, I was thinking a many-to-one relation made sense but as it
> > > > happens I now need to track some info about the relationship between
> > > > the sample and materials tests by adding an 'Approved' property, among
> > > > other descriptors.
>
> > > > My thought was to invert the relationship to a one-to-many (with
> > > > Sample holding the collection) and wrapping the reference to
> > > > IMaterialsTest inside an ValueObject called descriptor, but that would
> > > > be tough since IMaterialsTest has many implementations.
>
> > > > Would you recommend introducing something like SampleTestDescriptor as
> > > > a ValueObject and removing the direct references to the entities in
> > > > the object model?
>
> > > > Assuming I don't want a big table called 'MaterialsTest' and use the
> > > > joined-subclass strategy in NHib, how else can I model or map
> > > > something like this?
>
> > > > thanks
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
