I have been experimenting with O2O: generating DTO's from Entities, modifying / creating DTO's and updating the model using the following code:

var mapper = new Mapper(session, m_mappingDescription);
var comparisonResult = mapper.Compare(originalDtoGraph, modifiedDtoGraph);

Here are the issues I have at this moment in my learning of O2O:

  1. There seems to be a small error in the ObjectMapperSample, specifically in method Client.CustomerManager.SaveChanges(). It is necessary to clone the Customers graph which is up to date following the mapped keys replacement into originalCustomers after each save to the service. Otherwise, after the first save, both Customers & originalCustomers refer (points) to the same List<customerdto> and there is no more changes detected.

  2. When I create or modify concrete Entities directly, their constructors and override methods (e.g. OnSetFieldValue() method) get called correctly. When I create or modify entities "indirectly" via Operations.Replay() following DTO modifications, the changes do get saved to the database but the concrete Entities constructors nor override methods do not get called. I verified that with both the ObjectMapperSample and my own test project. I do not know whether this is be design or a problem with V4.4 Beta 1 but this bypasses any custom business logic that would be coded in the concrete entities. Is there any special steps to do here to call up the concrete entities code?

  3. In my own test project, the optimistic lock on the Version fields seem also to be completely bypassed when changes are applied from Operations.Replay. If I modify the concrete entities directly, while fooling around with the Version columns in the database, I can properly create optimistic violations (using a ClientProfile to release the locks in the database while I manipulate it manually). But using Operations.Replay from DTO changes, I could never get optimistic lock violations...

I am using V4.4 Beta 1 Build 6962 to evaluate DO4 at the moment.

Finally, is anyone using O2O for N-Tier applications? Although there are some really good ideas in its implementation, particularly the capability to extract the difference between 2 graphs and express it as an OperationLog, it feels inefficient to have to send the 2 graphs back to the service to end up saving only the difference between them. This can be particularly problematic when large fields are involved that rarely change (e.g. image).

It would seem interesting to mix 2 existing DO4 ideas here: have self-tracking DTO's (implemented with some PostSharp magic to make those DTO's as clean as the DO4 Entities) that could generate the OperationLog "on the fly" while modifications are done on them. Then, it would be a simple matter of sending the log to the service as a more efficient means to transport only the changes. As anybody already tried to go in a similar direction? Any major problems expected?

asked Jan 19 '11 at 22:02

pcournoyer's gravatar image


It seems O2O is not a very popular topic...unless all those interested are too busy using it and do not come here often :-)

Anyway, I will continue on this front but will also look at the DisconnectedState which seems to have a pretty strong feature set. One quick question: does the DisconnectedState work in Silverlight 4?

Any comment (good or bad) is welcome...

(Jan 24 '11 at 09:17) pcournoyer pcournoyer's gravatar image

Hello Patrick,

Unfortunately, SL is not supported. As for the main question, I'm hoping that the chief OperationFramework architect will be available soon (he was absent for a while) and give his opinion on the subject.

Sorry for the delay.

(Jan 24 '11 at 09:28) Dmitri Maximov Dmitri%20Maximov's gravatar image

Thanks Dmitri for the update.

(Jan 24 '11 at 10:02) pcournoyer pcournoyer's gravatar image

One Answer:


  1. O2O mapper really doesn't care about rebuilding the graph after saving (mainly, because it's a pretty tricky problem). It's implied working set is fully refreshed (reloaded from server) after this action.

  2. That's by design: we consider modifications done there are low-level actions, so we fully turn off BLL rules (i.e. invocation of overridable methods and Session.Events, but not Session.SystemEvents). We can easily turn this into an option - I understand this behavior is actually pretty subjective. Also, it's impossible to invoke correct (similar?) constructors: we simply can't extract this info by comparing two graphs.

  3. You must implement IHasBinaryVersion in your DTOs to make this part working - i.e. declare support of this interface and and public byte[] Version { get; set; } to the DTO. When it's done, O2O mapper extension for DO (O2O mapper is implemented in generic way in Xtensive.Core, but Xtensive.Orm extends it to support Entity type) will serialize Entity.VersionInfo tuple into it, and will use such values on saving changes.

Finally, is anyone using O2O for N-Tier applications?

I'm not sure - we get some support requests about this API, but likely, it wasn't ever used in production. It's clear here we developed something that is unusual \ unexpected. So quite likely, we'll refactor this API in future.

... it feels inefficient to have to send the 2 graphs back to the service to end up saving only the difference between them.

That's one of issues. O2O API is designed in implication we can't make the client to run our code at all. The link above describing newly proposed API implies some part of our framework (i.e. Xtensive.Core) is available on the client side.

It would seem interesting to mix 2 existing DO4 ideas here ...

Probably, even this will be implemented. Such approach has its own cons (i.e. client-side entities aren't POCO anymore) as well as pros. I think we should go step-by-step here - i.e. add an API relying on change extraction first, and further extend it with self-tracking support.

answered Jan 26 '11 at 05:08

Alex%20Yakunin's gravatar image

Alex Yakunin


Thanks Alex for the complete answer. Some comments: 2. I think it is necessary to go through BLL when saving all changes, no matter the source. I do not think it is realistic to expect the client application using DTO's to implement all business rules (maybe some to improve user experience but not all). As for constructor, I understand your point, maybe support only for default constructor... 3. Thanks, I figured there was a trick to this...

For client side DTO's not being fully POCO, well yes it is a tradoff but a minimal dependency is acceptable in my point of view.

Thanks again, Patrick.

(Jan 26 '11 at 10:07) pcournoyer pcournoyer's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview


Once you sign in you will be able to subscribe for any updates here



Asked: Jan 19 '11 at 22:02

Seen: 4,756 times

Last updated: Jan 26 '11 at 10:07

powered by OSQA