Exposing Associated Entities In Ria Services SP1 and EF 4.1 POCO

We recently upgraded a Silverlight 4 app that was using RIA Services and EF 4.0 with EDMXs to RIA Services SP1 and EF 4.1 using POCOs. The upgrade was well worth while, but it appears that RIA is now playing differently with how it exposes Associated Entities on the Client.

For example say we have the following EF POCOs which are also our RIA Entities:

public class Building
{
   public Building()
   {
     Rooms = new List<Room>();
   }

   [Key]
   public int? BuildingID { get; set; }

   public string Name {get; set;}

   [Association("Building_1-*_Rooms", "BuildingID", "BuildingID")]
   [Include]
   [Composition]
   public ICollection<Room> Rooms {get; set;}
}


public class Room
{
   [Key]
   public int? RoomID { get; set; }

   [Required]
   public int? BuildingID { get; set; }

   public string Name {get; set;}

   [Association("Building_1-*_Rooms", "BuildingID", "BuildingID", IsForeignKey= true)]
   [Include]
   public Building Building {get; set;}

   [Association("Room_1-*_Desks", "RoomID", "RoomID")]
   [Include]
   [Composition]
   public ICollection<Desk> Desks { get; set; }
}

public class Desk
{
   [Key]
   public int? DeskID { get; set; }

   开发者_StackOverflow中文版[Required]
   public int? RoomID { get; set; }

   public string Name { get; set; }

   [Association("Room_1-*_Desks", "RoomID", "RoomID", IsForeignKey = true)]
   [Include]
   public Room Room { get; set; }
 }

Building is the parent of Room and Room is the parent of Desk. The Association attribute defines these relationships for RIA. We then expose these Entities with a simple service that has CRUD for all three entities

public class BuildingDomainService
{

 var _context= new BuildingEFContext(); //Lets just say this is our EF Context that has all three types on it

 public IQueryable<Buildings> GetBuildings()
 {
      return _context.Buildings.Include(x => x.Rooms.Select(y => y.Desks));
 }

 public IQueryable<Rooms> GetRooms()
 {
      return _context.Rooms.Include(x => x.Desks);
 }

 public IQueryable<Desk> GetDesks()
 {
      return _context.Desks;
 }

 //Empty Update and Insert Methods to allow editing on client
 public void UpdateBuilding(Building building){}
 public void InsertBuilding(Building building){}
 public void DeleteBuilding(Building building){}

 public void UpdateRoom(Room room){}
 public void InsertRoom(Room room){}
 public void DeleteRoom(Room room){}

 public void UpdateDesk(Desk desk){}
 public void InsertDesk (Desk desk){}
 public void DeleteDesk (Desk desk){}

}

On the client the BuildingDomainContext that is generated from the BuildingDomainService has the three Exposed Methods (GetBuildingsQuery(), GetRoomsQuery(), and GetDesksQuery()), but only a single EntitySet of type Building, the service does not expose an EntitySet for Room or Desk.

In some places in our client app we want to maintain this object Hierarchy, but in others we may only want to get a slice of it, For example if we want to get look at and edit Desks in a Room, but don't care about Rooms in a Building. Because RIA Services does not expose an EntitySet for Room or Desk we cannot edit either of these without also pulling the parent Building.

Is there anyway to maintain these associations in RIA, but also allow for editing a part of this hierarchy, without having to pull in the top-most parent?

I'd recommend reading this post on composition. When you add [Composition] attributes, it affects how the data flows from server to client as well as which entities you can edit independently.

Perhaps using BuildingDomainContext.EntityContainer.GetEntitySet<Room>() method would expose the EntitySet you are looking for. You could put this in the partial implementation of the BuildingDomainContext on the client-side. For example:

public partial class BuildingDomainContext
{
    public EntitySet<Room> Rooms
    {
        get
        {
            return EntityContainer.GetEntitySet<Room>();
        }
    }
}