David, Thanks for your comment.
My code was not meant to discuss that a method should be used to maintain the relationship. I know it is necessary and recommended. I had specific questions about nHibernate which I need help to clear up Thanks, Andrew. On Sat, Dec 29, 2012 at 12:52 AM, TheCPUWizard <[email protected]>wrote: > I sent the message below privately since it was not directly related to > the nHibernate issue…but am now including it as a public response since it > has been mentioned again on the public thread….**** > > ** ** > > ** ** > > ** ** > > ** ** > > -----Original Message----- > From: TheCPUWizard [mailto:[email protected]] > Sent: Friday, December 28, 2012 11:47 AM > To: 'Andrewz' > Cc: 'Gunnar Liljas' > Subject: RE: [nhusers] questions about sql logging and the Inverse in a > one to many relationship**** > > ** ** > > Andrew,**** > > ** ** > > As Gunner pointed out, it allows for ambiguous data (which is being kind, > I would use a harsher term). Twenty years ago, Scott Meyers made a great > statement: "Write software that is easy to use correctly, and difficult to > use incorrectly". A design which requires multiple steps (one of which > could be accidently left out) fails the second part of this. It would be a > much better design if the act of performing EITHER of the operations > automatically performed the other.**** > > ** ** > > This may seem like a trivial case, but over the years, I have consistently > found that when there is one such design element, there are almost > invariably others of similar (or worse) nature. Over the lifecycle of the > product, the net effect can be quite costly.**** > > ** ** > > David**** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Andrewz > *Sent:* Friday, December 28, 2012 5:17 PM > *To:* [email protected] > *Subject:* Re: [nhusers] questions about sql logging and the Inverse in a > one to many relationship**** > > ** ** > > Gunnar, **** > > ** ** > > I know that I should use a method to maintain the relationship.**** > > That's not the point of my question.**** > > And TheCPUWizard said something else, that it's a bad design which I do > not understand why he says that.**** > > ** ** > > In my post, I have specific questions regarding specific things I do not > understand.**** > > > > On Friday, December 28, 2012 5:14:17 PM UTC+2, Gunnar Liljas wrote:**** > > It's an *inconvenient* design, in that it requires two steps, and > allows for ambiguous data. > > One small thing you can to is to create a group.AddUser method, which > both adds the user and sets its group. > > The next step would be to not expose group.Users as a collection (map > it to a backing field instead and just expose the property as an > IEnumerable<User>), so that its impossible to use Users.Add directly. > > /G **** > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/nhusers/-/xVIA8QVCVQgJ. > 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.**** > > -- > 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. > -- 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.
