1

We have a typical multi-tier/layer architecture. Application + WCF Service + Repository/EF4/Database.

We are using a customized version of the EF POCO T4 template to generate our entities, that we use across the tiers/layers. We have decided not to use DTO, because of the additional time/work involved.

An example object would be a forest which could have navigation properties of trees which could have navigation properties of leaves.

What is the best approach to add leaves and deal with the object graph? The data is being imported from the client side, so we don't necessarily know if the parent forest/tree already exists in the database.

  1. Query service and retrieve any existing related objects. Attach graph for related objects or create new objects and attach graph on the client side. example: public Forest GetForest(string forestid) then --- public void AddLeaf(Leaf leaf)

  2. Create the forest, tree, and leaf objects on the client side and attach the graphs. Send the leaf object across and then on the server side perform logic to compare objects to existing objects in the database. Strip graphs if required, add items that do not exist and/or attach to existing objects. example: public void AddLeaf(Leaf leaf)

  3. Create the forest, tree and leaf objects on the client side, but don't attach the graphs. Send the objects across and then on the service side perform the logic to compare objects to existing objects in the database. Add items that do not exist and/or attach to existing objects. example: public void AddLeaf(Leaf leaf, Tree tree, Forest forest)

The question boils down to where should the logic take place to attach the graphs of these related objects. On a side note I am a little concerned about the "fixup" logic for the navigation properties when dealing with graphs being serialized and deserialized. It seems like that could become an expensive opearation.

Note: The client application is a windows service that is importing data...so it is not necessarily a light weight client. (We are not necessarily afraid of adding logic to it.)

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
Blane Bunderson
  • 513
  • 5
  • 11
  • use DTO's: passing object graphs between layers sometimes seems like a good idea, but it causes headaches! – Mitch Wheat Jan 08 '11 at 06:18
  • I think on our next revamp of our architecture, we will incorporate DTOs, but looking for a way to do it somewhat automatically like with automapper. – Blane Bunderson Jan 09 '11 at 01:19

1 Answers1

1

I had similar question few months ago. After playing a lot with this problem my final decission is to use your third solution (my client is always web application). This solution requires writting a lot of code and it includes some additional database queries because each time you want to update your objects you have to load whole object graph first. Reason for this is that when working with detached objects you have to deal with change tracking manually.

When you use third solution you can also involve DTO and transfers only really needed data between client and server.

In case of statefull client (windows app written in .NET or maybe Silverlight) you can also use self tracking entities and your first approach. Self tracking entities are implementation of Changeset pattern. They can track all changes after detaching from context but you have to load your entities first from DB. Self tracking entities are not a good choice in case of web application client or service consumed by non .NET client.

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • I was leaning toward item 3 because we do use mvc for the interface in most cases. We do have state on our base poco class. So we can use the change tracking...but like you are said they are detached and must manually track change. – Blane Bunderson Jan 09 '11 at 01:23