I'd say lean on the side of unidirectional unless your domain requires otherwise. I tried to come in and rescue an app where they had modeled everything as a gigantic object model, and with no lazy loading (NH was hidden completely behind WCF services) and a request for a single leaf entity resulted in a massive amount of queries.
The architecture was completely naive, but luckily a few snips on the mappings and we had reduced startup queries from ~900 to something like ~20. I wrote about this here: http://flux88.com/blog/blame-nhibernate-why-not On Tue, Feb 17, 2009 at 11:52 AM, Nuno Lopes <[email protected]> wrote: > > > Let me tackle the inverse: When to use Unidirection Mappings. > > IMHO. > > You mainly use unidirectional mapping when you need to decouple one > object from the other for some reusability or architectral reason. In > all other cases, bidrectional mappings increases flexibility for > distribution of business rules not to mention performance. > > Say for instance, you have Company[1:N]Deparment[1:N]Worker. > > If adding aWorker to a Deparment requires business rules to be checked > by aCompany (say aCompany holds a Emplyment Policy) then > aDepartment.AddWorker(aWorker) migh need to call > this.Company.CheckPolicy(aWorker). On the other side, you might want > to ask aCompany for its Department's. > > You could implement this with a unidirectional association, but it > would be non intuitive and prone to usage errors aDepartment.AddWorker > (aWorker, aCompany) (ouch awful) or aCompany.AddWorkerToDeparment > (aDepartment, aWorker (worse), or aCompany.AddWorkToDepartment > (aDepartment.DepartmentID, aWorker) (even worst). > > > The problem with bidirectional associations is that you need to both > do aCompany.Departments.Add(aDepartment) and aDepartment.Company = > aCompany. But is a minor thing to ask (Read Streamlined Object > Modeling for further info). > > Nuno > > > > On Feb 16, 11:24 pm, "[email protected]" > <[email protected]> wrote: > > Hi! > > > > Been wondering for a time how others usually deals with the parent > > when mapping collections. > > > > Say, we have a Group class which when its created should be filled > > with users. > > > > Group group = new Group("My new group"); > > IList<Users> users = Session.Get<User>(); > > group.AddMembers(users); > > > > Would you in this mapping add a bidrectional mapping to users to get > > which group they're in? Or would you just map the group-id to a > > perhaps, maybe, a ParentID property on Users? > > > > I'll find it hard to know when to use bidirectional mappings. Just > > today i encountered a similar problem when adding children to a > > parents collection which were mapped by the ID only on the child side. > > > > //Code > > public class Parent ... > > public void AddChild(string childName, object[] OtherParams) { > > Child c = new Child(childName, this, OtherParams); //Add "this" so we > > know the parent > > Children.Add(c); > > > > } > > > > and in the Child class > > > > public class Child ... > > public Child(string name, Parent parent, object[] otherParams) { > > this.Name = name; > > this.ParentId = parent.Id //Now this won't work cause the parent > > hasn't been saved yet, could probably save the Parent in a private > > variable and let the ParentId get property check that variable, Is it > > possible to solve this with cascading? > > > > } > > > > So, hope I expressed myself god enough, english isn't my primary > > language! > > > > Thanks for any answers > > //Kenny > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
