Print Page | Close Window

Saving Changes to POCOs

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3829
Printed Date: 13-May-2026 at 1:01am


Topic: Saving Changes to POCOs
Posted By: matt.cavagnaro
Subject: Saving Changes to POCOs
Date Posted: 30-Nov-2012 at 8:55am
I've recently implemented a ConventionBased ServiceProvider to Query for a FCC POCO object which is a subset of an existing Entity.

I have not been able to figure out how to persist changes made to the POCO to the table it is a subset for during SaveChanges.

I've read through these links multiple times and have not been able to figure out how to make this work.
http://drc.ideablade.com/xwiki/bin/view/Documentation/poco-service-provider-class - http://drc.ideablade.com/xwiki/bin/view/Documentation/poco-service-provider-class
http://drc.ideablade.com/xwiki/bin/view/Documentation/poco-save-mechanisms - http://drc.ideablade.com/xwiki/bin/view/Documentation/poco-save-mechanisms

I've tried using the EntityManager from the POCO to query for and save changes to the original object in the DB but an error is thrown stating recursive saves are not supported.

Is there any better documentation/code samples for this?


Replies:
Posted By: kimj
Date Posted: 30-Nov-2012 at 10:38am
As you've found, you can't use an EntityManager from your POCO service provider or adapter to save an entity.  The save is recursive to DevForce, and once a save is in progress additional SaveChanges calls are not supported.
 
In general, POCO is not really intended for database-backed objects, and any insert/update/delete activities should not be using an EntityManager in the provider or adapter.
 
I'm not sure I understand your use case, though, and maybe POCO is not a good fit for this anyway.  If your FCC type is a subset of an existing entity type, will standard inheritance work - maybe with an abstract base entity having the FCC and other entity type as sub-types?   More information on inheritance is here - http://drc.ideablade.com/xwiki/bin/view/Documentation/model-advanced - http://drc.ideablade.com/xwiki/bin/view/Documentation/model-advanced .
 
 
 

Posted By: matt.cavagnaro
Date Posted: 30-Nov-2012 at 10:50am
My use case is as follows.

Given a DB backed entity like Player
class Player()
{
    Guid UniqueID { get; set; }
    string FirstName { get; set; }
    string LastName { get; set; }
    bool IsActive { get; set; }
    string TeamName { get; set; }
    string Position { get; set; }
    byte[] Picture { get; set; }
}


And a POCO class for a query on Players to project into:
class PlayerLite()
{
    Guid UniqueID { get; set; }
    string LastName { get; set; }
    bool IsActive { get; set; }
}


I need to query many objects like Player at once. to make the query more performant I've used a POCO to only pull down the data I need to interact with. In reality my Player table is much larger than this. And I'd like to avoid pulling down heavier properties like Images and other Navigation Properties.

In the portion of the app this is used for the User is only ever expecting to modify a handful of properties for a given Player entity.

I guess I don't understand the function of wanting to save the POCO to somewhere that is not it's data source, like an XML file. To me this sounds like I could query for a subset of the object I wanted to modify, make a few changes, and be able to map the properties on the POCO back to the DB backed Entity.

Is there another way you'd suggest doing this?

Posted By: kimj
Date Posted: 30-Nov-2012 at 12:31pm
You have a few different options.
 
I assume you're projecting into the PlayerLite type from a query, so you shouldn't need a POCO service provider or adapter at all.
 
One option would be to query for the full Player entity when changes are required.  The Player would then be changed and saved.
 
Another option would be to make changes to the PlayerLite object, and in an EntityQuerySaveInterceptor intercept the save of the PlayerLite, and there query for and modify the Player in the provided EntityManager.  You'd also have to detach the PlayerLite from the EM so that DevForce won't still try to save it as a POCO, or alternately keep a stub POCO save method.
 
Another option would be to use table splitting for these entities, so that both are full-fledged entities with a 1-1 relationship between them, and either could be modified as needed. 


Print Page | Close Window