locked
Why do associations require foreign keys? RRS feed

  • Question

  • This is perhaps a noob question, but i hope someone is kind enough to provide an explenation;

    I'm struggling around with RIA services to expose my nhibernate domain model in silverlight. The recurring problem seems to be that RIA Services needs foreign keys on the domain model. These are required for association annotation. This also means that many-to-many relationships won't work. What I would like is to keep my model a domainmodel, and not pervert it to a table-like representation. AFAIK, ADO.NET Data Services just provides entities, and any references/identities are handled internally.

    Why is this different in RIA Services? Is this a deliberate design choice? Why should I (need to) care about foreign keys and many-to-many-linking objects?

    TIA,

    Patrick

    Friday, September 25, 2009 8:29 AM

Answers

  • That is a very nice link Ardman. I would also point out a couple of blog entries that I have made on this subject.

    It was a design decision, the foreign key requirement is what gives RIA Services its flexible, extensible design and a big part of why RIA Services has better performance than ADO.NET Data Services. However, I don't want to bypass the important point about polluting the NHibernate model with foriegn keys.  The problem there is really that there isn't a dedicated NHibernateDomainService, not that RIA Services requires NHibernate's model to be changed. RIA Services doesn't require that Entity Framework and L2S have their foreign keys exposed in the model because their respective DomainService types and code generators extract that information automatically.

    I would predict that we could see someone come up with a real NHibernateDomainService in the RIA Services V2 timeframe after the move to T4 templates. That would take care of your server side problems. The existance of the foreign keys client side isn't going to change, that is a structural requirement of how RIA Services is put together.

    Friday, September 25, 2009 10:22 AM

All replies

  • That is a very nice link Ardman. I would also point out a couple of blog entries that I have made on this subject.

    It was a design decision, the foreign key requirement is what gives RIA Services its flexible, extensible design and a big part of why RIA Services has better performance than ADO.NET Data Services. However, I don't want to bypass the important point about polluting the NHibernate model with foriegn keys.  The problem there is really that there isn't a dedicated NHibernateDomainService, not that RIA Services requires NHibernate's model to be changed. RIA Services doesn't require that Entity Framework and L2S have their foreign keys exposed in the model because their respective DomainService types and code generators extract that information automatically.

    I would predict that we could see someone come up with a real NHibernateDomainService in the RIA Services V2 timeframe after the move to T4 templates. That would take care of your server side problems. The existance of the foreign keys client side isn't going to change, that is a structural requirement of how RIA Services is put together.

    Friday, September 25, 2009 10:22 AM
  • Interesting comment from Nikhil on your blog:

    "...
    we look at entities as a flat set of lists, with associations that can be used to navigate, rather than define ownership or lifetime
    ..."

    In that case: why isn't there a generic DataSet implementation by NRS? I mean we're talking about rows and relationships in that case, right?

    Saturday, September 26, 2009 10:40 AM
  • Thanks, both replies answered my questions. Unfortunately my basic problem goes unsolved. (nhibernate support) :(

    Saturday, September 26, 2009 1:35 PM
  • In that case: why isn't there a generic DataSet implementation by NRS? I mean we're talking about rows and relationships in that case, right?

    It is an interesting question. You know, I think if I tried I could come up with some plausible reason, but I think the real problem is a lack of will to do it. The number of people who are both able to code a custom DomainService for Datasets and willing to do so probably very small, and I don't think those people are working on the RIA Services team.

    Saturday, September 26, 2009 5:13 PM
  • The number of people who are both able to code a custom DomainService for Datasets and willing to do so probably very small, and I don't think those people are working on the RIA Services team.

    Don't get me wrong, I'm not a big fan of the DataSet, just the NRS-entities look much like DataRows especially in combination with the ViewModel. It was more in the light of http://blogs.msdn.com/pablo/archive/2008/11/01/ado-net-data-services-in-windows-azure-pushing-scalability-to-the-next-level.aspx. I wonder what the bonus of having full blown NRS entities is when they are not full blown entity trees during save in the domain service and when you can't push them from the client to server for custom operations.

     

    Sunday, September 27, 2009 3:46 AM
  • Lightbulb! Nikhil did state on my blog that a future version of NRS will have the ability to have a true parent/child relationship mode where child does depend on the parent. Maybe that change also answers your problems on Order/OrderLines.

    Sunday, September 27, 2009 10:50 AM