locked
Difficulties using EF (Code First) with WCF RRS feed

  • Question

  • Hi

     

    After some initial prototyping with the CTPs of EF Code First we decided to start using the release version for our production code.  Although we really like EF Code First we’re found that a number of difficulties have arisen from using EF Code First in conjunction with WCF (and thus working with entities that are detached from the context).

    To put this another way, when using EF directly everything is all very nice and easy, but bring WCF into the mix and it becomes more complex and messy.  Now although this is to be expected I’m hoping there some things that could be done to make it simpler.

    It would therefore be helpful to hear from the EF team if and when you’re planning to address these issues.

    For example, we have a client, which connects via WCF to a windows service.  The following is a simplified flow of events of inserting a new customer record:

    1.  A new Customer instance is created on the client.
    2. The user specifies a Country to associate with the Customer – we therefore make a service call to get the Country instance.  This is then assigned to the Customer.
    3. A Save method is then called on the service – we pass to this the Customer (which has the associated Country assigned to it).

    In reality our object graphs are a lot more complex than what I describe above but it illustrates how we work.

    The problems we’re encountering are as follows:

    Setting the entity state

    When the service receives the customer and it is attached to the service it assumes all entities in the graph are of Added state.  We therefore have to set the entity state for all objects in the graph.  Rowan Miller (Microsoft) mentions in a post I made a few months back that you’re looking at whether you can provide something that just works:

    http://social.msdn.microsoft.com/Forums/en-US/adonetefx/thread/4d8af696-6054-4acb-b616-430eecf86b3d

    Is this something you are still working on?

    Change to foreign keys not updated

    If I retrieve an entity, then update it so it references a different entity, I'm finding that it saves with the original foreign key value.  This again appears due to working with the entity on the client and then sending it to the service – the service/context doesn’t know that the relation is modified.  The solution seems to be to add a foreign key property to the entity:

    http://stackoverflow.com/questions/5729031/ef-4-1-code-first-change-to-fk-value-not-updated-when-using-new-context-over-wc/5729844#5729844

    This leads though to a less OO design and more messing around when assigning entities.

    Could you confirm if this is the best workaround at present and whether you have any plans to address this?

    Duplicate entities in the object graph

    In some situations we have duplicate entities in the object graph.  Each of the duplicates are retrieved via separate service calls so although they have the same ID they don’t reference the same object in memory.  This is best explained here:

    http://stackoverflow.com/questions/6280731/ef-4-1-code-first-duplicate-entities-in-object-graph-causes-exception/6284699#6284699

    Again the workaround isn’t very nice.  I would say this is something that is quite likely to happen?  Do you have any plans to address this?

    Many thanks

    Paul.

    Thursday, June 9, 2011 12:27 PM

Answers

  • Hi Paul,

    EF team actually addressed this problem long time ago. The solution is called Self tracking entities (STE) but the template itself doesn't work with EF Code first at the moment. I personally don't like STEs because they are only partial solution with very specific and limited usage. Because of that I don't call them solution but workaround.

    The problem itself is not related only to entity framework but probably to any ORM tools. You must instruct ORM how changes should be processed. The main power of ORM tool is in attached mode - it is truth for EF as well and ADO.NET team put a big effort to support that scenario. The biggest problem is that currently almost any business application is developed either as web solution or solution consuming services (smart client, silverlight, etc.) so fully attached scenarios are very rare.

    If you are inserting a new entity related to existing entities you should implement a logic which will handle the situation for you on the server side because only you know what changes are allowed and only you know how to identify changes in incoming POCO graph. It is not easy but that is the price for using ORM tool. In case of updating existing object graph the best way to go is loading current state from the database and merge changes passed from the client into that state (into attached object graph) - here is very big gap in EF because it doesn't provide any ApplyChanges for entity graph nor any helper methods to do it more easily. I wrote about it more in separate answer on Stack Overflow.

    I also don't like polluting entity model with foreign key properties but it is at the moment the simplest way to achieve some scenarios. Introducing Foreign key associations were in my opinion very bad decision as well as whole DbContext API (I will wrote about that soon).

    Best regards,
    Ladislav

    • Marked as answer by Paul Touzel2 Tuesday, June 14, 2011 10:02 AM
    Friday, June 10, 2011 8:18 AM

All replies

  • Hi Paul,

    EF team actually addressed this problem long time ago. The solution is called Self tracking entities (STE) but the template itself doesn't work with EF Code first at the moment. I personally don't like STEs because they are only partial solution with very specific and limited usage. Because of that I don't call them solution but workaround.

    The problem itself is not related only to entity framework but probably to any ORM tools. You must instruct ORM how changes should be processed. The main power of ORM tool is in attached mode - it is truth for EF as well and ADO.NET team put a big effort to support that scenario. The biggest problem is that currently almost any business application is developed either as web solution or solution consuming services (smart client, silverlight, etc.) so fully attached scenarios are very rare.

    If you are inserting a new entity related to existing entities you should implement a logic which will handle the situation for you on the server side because only you know what changes are allowed and only you know how to identify changes in incoming POCO graph. It is not easy but that is the price for using ORM tool. In case of updating existing object graph the best way to go is loading current state from the database and merge changes passed from the client into that state (into attached object graph) - here is very big gap in EF because it doesn't provide any ApplyChanges for entity graph nor any helper methods to do it more easily. I wrote about it more in separate answer on Stack Overflow.

    I also don't like polluting entity model with foreign key properties but it is at the moment the simplest way to achieve some scenarios. Introducing Foreign key associations were in my opinion very bad decision as well as whole DbContext API (I will wrote about that soon).

    Best regards,
    Ladislav

    • Marked as answer by Paul Touzel2 Tuesday, June 14, 2011 10:02 AM
    Friday, June 10, 2011 8:18 AM
  • Any update? Was your question solved?

    Best Regards,


    Larcolais Gong[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, June 13, 2011 8:25 AM
  • Hi Ladislav

    Thanks for your answer.  This helps to clarify where EF is in regards to this.

     

    Hopefully this is something that the EF team can look at making easier, because as you say working in fully attached scenarios are rare.

     

    My main concern is that some of the code in our service to deal with these issues is becoming more complex than I would have liked, and you start to think to yourself, should we really be using EF?  Or should we write our own data access code i.e. don’t use an ORM framework.  We’ll persist with it though and see how it goes.

    Thanks.

     

    Paul. 

     

    Tuesday, June 14, 2011 10:02 AM