locked
External + Association for Spanned Databases? RRS feed

  • Question

  • I'm trying to add a property on an Account entity, Membership, which points to a record in a table that belongs to another database that Account is owned by.  It appears that the Association attribute looks for an association name that exists in the database of the owning entity (Account, in this case).  However, this relationship spans two databases.  Is this possible?

    Thanks ya,

    Michael

    Thursday, August 20, 2009 9:37 AM

Answers

  • Another option is to examine the advanced scenario in section 20.3.  You can add the necessary client code in partial entity type definitions to enable cross-DomainContext references client-side.  It's a little bit more work but it should allow you to enable this scenario.

    Thursday, August 20, 2009 4:44 PM

All replies

  • Hey Michael,

    You would need to have multiple domain context for this.

    Please look at Chapter 20  http://go.microsoft.com/fwlink/?LinkID=144687

    The example is a good start, its not all the way tehre.

    Alternatively you can also use DomainContext.AddReference for this.

    --Deepesh

    Thursday, August 20, 2009 2:44 PM
  • Deepesh,

     I actually have been reading chapter 20.  That is where I found out about the External and Association attributes. :)  It appears, however, that these attributes only work with multiple domain contexts if all the contexts are using the same underlying ObjectContext.  I'm wondering if this is possible to do with multiple ObjectContext's (spanning two different databases).

    Thursday, August 20, 2009 2:53 PM
  • Why not have 2 Domain Services. For E.g.

    DomainServiceA has your accounts

    DomainServiceB has your membership

    In the metadata for accounts add a new property called

    Public Membership memberShip

    Add the following attributes

    [External][Association("Accounts_Membership", "MemberShipId", "AccountId", IsForeignKey = true)]

     

    Compile so both the DS and metadata are code gen'ed.

    On the Client

    New up both the DomainContext's

    DomainContextA dcA = new DomainContextA();

    DomainContextB dcB = new DomainContextB();

    then do this dcA.AddReference<MemberShip>(dcB);

     

    Call load for both the domain contexts.

     

    This should get you there...

    let me know how this works out.

    Thanks

    Deepesh

     

     

    Thursday, August 20, 2009 3:13 PM
  • Indeed. I tried doing exactly that.  However, the problem is with the association name.  The association does not exist in the underlying ObjectContext, so the client-generation task balks when it tries to execute.

    Thursday, August 20, 2009 3:23 PM
  • Another option is to examine the advanced scenario in section 20.3.  You can add the necessary client code in partial entity type definitions to enable cross-DomainContext references client-side.  It's a little bit more work but it should allow you to enable this scenario.

    Thursday, August 20, 2009 4:44 PM
  • Again, the problem comes with the association.  It's not so much of multiple services/client contexts but the underlying ObjectContext.  The AssociationAttribute requires an association name that exists within the ObjectContext.  In this case I am spanning two ObjectContexts (each represents a database), so the association does not exist.

    I'm just assuming this is impossible so I'm currently writing (more :P) custom code to get what I need to work. :)

    Thursday, August 20, 2009 4:51 PM
  • Why not have 2 Domain Services. For E.g.
    DomainServiceA has your accounts
    DomainServiceB has your membership

    Isn't the whole point of having domain services the fact you want to abstract the database? So in this case I assume the approach would be to write a POCO domain service with a custom mapping to the various databases. I can imagine that you want the same entity structure in your business logic processing as well. So it would not only be the client that needs the Account.Memberships, most likely it will be some business logic as well, or?

    Friday, August 21, 2009 3:04 AM
  • OK!  Many thanks and much appreciation to Warren for taking the time to private message me and making sure I fully understand things. :)

    I have managed to make this work with the advanced example shown in 20.3.  It was a little tricky but I got it to start clicking.  This will save me a bunch of work!

    As a suggestion: I would strongly recommend removing the "Name" property from the client-side AssociationAttribute.  This is what threw me off in my initial analysis of the proposed solution.  It turns out that the Name property isn't used.  Anywhere. :P  In my case it added confusion (I already have enough!) and kept me from implmenting this property in the first place.

    Anyways.  Thanks.  I have things working as desired.

    Friday, August 21, 2009 1:30 PM