I don't understand what you are talking about. Can you please be more specific instead of citing Meyers?
Do you say bi-directional is a bad design? What are you saying exactly? The code example I gave was only for the sake of the example. It's not a real life example. I made a mockup app to learn more how nHibernate works. Thanks, A On Saturday, December 29, 2012 12:52:27 AM UTC+2, TheCPUWizard 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] <javascript:>] > 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] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Andrewz > *Sent:* Friday, December 28, 2012 5:17 PM > *To:* [email protected] <javascript:> > *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] <javascript:> > . > To unsubscribe from this group, send email to > [email protected] <javascript:>. > 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 view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/8e_kZnHktzYJ. 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.
