There are several pieces: lazy initialization interceptor, relationship synchronizer, one common method that all persistent classes have to have, one custom attribute and IUserCollection implementation. I think I can salvage all of it even if I go with the IEnumerable approach. I might might put it on my blog when I get a chance.
On Dec 19, 8:33 am, Daniel Fernandes <[email protected]> wrote: > How long is a piece of string ? > If your project really needs you to develop such a collection and your > consumers are aware of what's going on then I think it's fine. > But as you said it, fully exposing a collection brings risks and it > might be better to just revert to public AddXXX/RemoveXXX methods. > I tend now to use IEnumerable because it's by its definition the items > references are read-only. > > On Dec 19, 2:15 pm, epitka <[email protected]> wrote: > > > Well, I have developed one that does all of the houskeeping, > > synchronize, raise events etc., but now looking at it, I am not sure > > that is the best way, since the API is not really revealing what is > > happening. I had to do this for the company I work(ed) for as they had > > a system that had it's own higher level language that allowed direct > > manipulation of collections. Now for example if you set a value in > > collection through indexer and there is already item on that index, it > > would remove item from the collection, synchronize if bi-directions, > > raise remove events, that insert item and the same index, synch, and > > raise add. That is a lot of work that happens that one might not be > > aware of. Only piece that was not in place was vetoing change. > > > On Dec 19, 8:04 am, Daniel Fernandes <[email protected]> > > wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
