Typical pattern is :
IEnumerable<Foo> Foos {
get { return _foos; }
}
bool AddFoo(Foo foo) {
// business rules here and references management (bi-directional
association, orphan children, multiplicity etc..)
}
bool RemoveFoo(Foo foo) {
// business rules here and references management (bi-directional,
orphan children, multiplicity, etc..)
}
There must be around some good IList`1 implementations giving you
callbacks for when an object is added/removed as in Linq2Sql (can't
remember the class name).
Daniel
On Dec 19, 1:06 pm, epitka <[email protected]> wrote:
> That is what I was after, as I've seen people providing Add/Remove
> methods and also exposing it as IList. I guess this post nails it down
> why.
>
> http://tomas.oo-systemutvecklare.se/articles/encapsulation.php
>
> On Dec 18, 11:12 pm, "Greg Young" <[email protected]> wrote:
>
> > I don't even expose it as a collection only as an IEnumerable
>
> > Why do you as a client care how I store it internally?
>
> > Cheers,
>
> > Greg
>
> > On Thu, Dec 18, 2008 at 7:49 PM, epitka <[email protected]> wrote:
>
> > > But how do you protect your collection from being changed; exposing it
> > > as read-only? But that is not intuitive, if client does not know that
> > > AddPerson is to be used you would get exception.
> > > Why is #2 not viable?
>
> > > On Dec 18, 9:29 pm, "Greg Young" <[email protected]> wrote:
> > >> 1. don't let collection be modified directly but use Add/remove and
> > >> enforce rule there
>
> > >> Have the aggregate root enforce the validation.
>
> > >> Cheers,
>
> > >> Greg
>
> > >> On Thu, Dec 18, 2008 at 7:25 PM, epitka <[email protected]> wrote:
>
> > >> > This is probably more a DDD question then NH. Let say you have
> > >> > observable collections that raise events before collection gets
> > >> > changed and after. Let's say you have a rule that only person's over
> > >> > 21 can be added to the collection. How would you handle this rule:
> > >> > 1. don't let collection be modified directly but use Add/remove and
> > >> > enforce rule there
> > >> > 2. create delegate that will check rule in OnChanging step and veto
> > >> > change
> > >> > 3. allow person to be added and run validate before persisting entity
> > >> > using NH events, basically allow entity to get into invalid state
> > >> > 4. manually invoke validation before commiting changes.
> > >> > 5. something else ?
>
> > >> --
> > >> It is the mark of an educated mind to be able to entertain a thought
> > >> without accepting it.
>
> > --
> > It is the mark of an educated mind to be able to entertain a thought
> > without accepting it.
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
