So when would you consider to use bidirectional association ?
anyway, you have an interesting point because if you read the book
"NHibernate in Action" then they talk about bidirectional association,
but they dont come across the points that you list here :) ... wich
seems a little bit odd since so many other books about programming
talks about keep things simple (k.i.s.s)
On Jan 12, 3:11 pm, "Ben Lovell" <benjamin.lov...@gmail.com> wrote:
> - Interdependency between the associated classes. Coupling is bad.
> - Complexity of maintaining the references when associating/disassociating.
> This can largely be handled by the AddXXX, RemoveXXX and proper
> encapsulation of the collection but still it is unnecessary complexity.
>
> On Mon, Jan 12, 2009 at 1:59 PM, Mark Jensen <don...@gmail.com> wrote:
>
> > interesting :)
>
> > I understand the fact that bidirectional are rarely used, but why
> > would you consider it to be a design flaw?
>
> > On Jan 12, 2:51 pm, "Ben Lovell" <benjamin.lov...@gmail.com> wrote:
> > > It would be /slightly/ better performance wise but you should avoid
> > > bidirectional associations where possible. Bidirectional association is
> > > rarely necessary and usually highlights a flaw in your modelling. The
> > > performance hit isn't exactly huge anyway and unless you've measured
> > you're
> > > making a pretty big assumption.
>
> > > On Mon, Jan 12, 2009 at 1:47 PM, Mark Jensen <don...@gmail.com> wrote:
>
> > > > woops.. i mean... im NOT sure how NH works...
>
> > > > On Jan 12, 2:34 pm, "Markus Zywitza" <markus.zywi...@gmail.com> wrote:
> > > > > Remove the not null-constraint from the database column.
>
> > > > > This is needed as NH works this way:
> > > > > 1) You save the parent
> > > > > 2) Parent cascades to newly created child
> > > > > 3) Child is saved with null FK
> > > > > 4) Parent updates child's FK
>
> > > > > On a bidirectional association, you can instead map the collection
> > > > > with Inverse=true and use the [BelongsTo]ed property to manage
> > > > > one-to-many relationships.
>
> > > > > However, I prefer giving up the not null constraint on foreign keys
> > > > > because unidirectional relations are generally less error-prone.
>
> > > > > -Markus
>
> > > > > 2009/1/12 Mark Jensen <don...@gmail.com>:
>
> > > > > > Yep :) but if i remove the property from the object I get the above
> > > > > > error
>
> > > > > > On Jan 12, 2:04 pm, Colin Ramsay <colinram...@gmail.com> wrote:
> > > > > >> You need the column in the DB but you don't need the property on
> > the
> > > > > >> post object.
>
> > > > > >> On Mon, Jan 12, 2009 at 12:44 PM, Mark Jensen <don...@gmail.com>
> > > > wrote:
>
> > > > > >> > Because if I remove the property(and ofcouce the belongsto
> > relation)
> > > > I
> > > > > >> > get an error ..
>
> > > > > >> > System.Data.SqlClient.SqlException: Cannot insert the value NULL
> > > > into
> > > > > >> > column 'BlogId'....
>
> > > > > >> > And as fare as I Know about databases and Nhibernate, I need the
> > > > > >> > blogId as my foreignkey. I dont see how nhibernate else would
> > know
> > > > how
> > > > > >> > to make the relation between Blog and Post if i remove BlogId
> > from
> > > > > >> > Post.
>
> > > > > >> > :/
>
> > > > > >> > On Jan 12, 11:34 am, "Markus Zywitza" <markus.zywi...@gmail.com
>
> > > > > >> > wrote:
> > > > > >> >> Then why do have the BlogId property in there? Simply discard
> > it.
>
> > > > > >> >> -Markus
>
> > > > > >> >> 2009/1/12 Mark Jensen <don...@gmail.com>:
>
> > > > > >> >> > haven't tested it yet, but is it really required to make it
> > > > > >> >> > bidirectional for this to work ?
>
> > > > > >> >> > because I only need it to go one way :/
>
> > > > > >> >> > On Jan 10, 2:41 pm, "Markus Zywitza" <
> > markus.zywi...@gmail.com>
> > > > wrote:
> > > > > >> >> >> > public class Post : BaseEntity<Post>
> > > > > >> >> >> > {
> > > > > >> >> >> > [Property("BlogId", NotNull = true)]
> > > > > >> >> >> > public Guid BlogId
> > > > > >> >> >> > {
> > > > > >> >> >> > get { return blogId; }
> > > > > >> >> >> > set { blogId = value; }
> > > > > >> >> >> > }
>
> > > > > >> >> >> [BelongsTo("BlogId")]
> > > > > >> >> >> public Blog Blog {get; set;}
>
> > > > > >> >> >> > }
> > > > > >> >> >> >> > anyway...it is not the ID on Post that is the problem..
> > it
> > > > is the
> > > > > >> >> >> >> > BlogID on Post that is empty after I persist Blog with
> > > > Blog.Save().
>
> > > > > >> >> >> Of course, it is changed in the DB but not in the object.
> > Call
> > > > > >> >> >> post.Refresh() to reload it. If you implement it as I have
> > > > written
> > > > > >> >> >> above, you could also set Blog on the post instance instead.
>
> > > > > >> >> >> public void AddPost(Post post)
> > > > > >> >> >> {
> > > > > >> >> >> posts.Add(post);
> > > > > >> >> >> post.Blog=this;
> > > > > >> >> >> }
>
> > > > > >> >> >> -Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to castle-project-users@googlegroups.com
To unsubscribe from this group, send email to
castle-project-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
