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.
