I already mentioned several times that I understand and I'm aware of what you are saying that setting the bi-directional relationship should be in a method. That's not the point of my question. I mentioned this 2 times already, this is the third time.
My questions were about specific issues in NH I am not able to understand. On Sat, Dec 29, 2012 at 3:51 AM, TheCPUWizard <[email protected]>wrote: > [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]] > 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 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. > -- 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.
