[I have also seen Andrews other two posts, but decided this was the best one to respond to.
What I am saying is that a design which requires a developer to perform multiple operations (in this particular case) A) Add the Person to the Group's Users collection AND! B) Set the Person's Group property Is a bad design/implementation. There are three [IMPO] better designs 1) Adding the Person to the Groups Users collection AUTOMATICALLY sets the Group property on the person instance. 2) Setting the Person's Group property AUTOMATICALLY adds the person to the group's Users collection 3) Use a "Behavioral method" [ often a static method of an operations type class] that is outside the Person and Group classes to perform the operation Note: Implementing 1 AND 2 is possibly better than either one individually. If 3 is implemented, it is usually better for it to be the only "real" way - although 1 and 2 can be semantic wrappers. However there are still potential problems when it comes to multithreaded operations [IMPO - ALL software should be designed to be thread safe, unless there is a provable reason to not do so] and even more where there can be multiple applications modifying the underlying database [which can often happen during scale-out, even with "private" data]. Now to bring this back to the topic for this group, getting great semantics at the OO/business level is often at conflict with ideal RDBMS implementations. ORM's are meant to bridge this gap, but my experience has unfortunately been that it is common for one or both to suffer in order to get an ORM configuration that does not have a lot of complications. In a great many cases, the changes needed to get better code design will have a major impact on the ORM and often some type of impact (where not constrained) on the RDBMS itself. This can cause significant rework (i.e. increased cost or debt) and I try to minimize this by ensuring that the code level is the most robust possible before delving into the ORM (especially how relationships are implemented) Hope this helps, David From: [email protected] [mailto:[email protected]] On Behalf Of Andrewz Sent: Friday, December 28, 2012 6:23 PM To: [email protected] Subject: Re: [nhusers] questions about sql logging and the Inverse in a one to many relationship 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. -- 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.
