Likely, the most obvious one is to write your own DTOs using the following pattern for conversion:

• Constructor accepting optional source parameter performing conversion of entity to DTO.

• virtual ApplyChanges method assigns all the values to underlying Entity.

Simplest example of this case is PersonEditModel type from new ASP.NET MVC sample - but during the nearest day I'm going to extend it to show more complex scenarios.

Pros: simplicity; works well for entities with small count of fields & relationships to process. Cons: requires manual tuning of conversion code after any changes to either entity or DTO; applying the changes made to collections (if this is necessary - normally this isn't handled this way) must be pretty complex (requires comparison with an old copy).

Another alternative is usage of our object-to-object mapper. It automates both forward and backward conversion, so in future it must be simply ideal solution in such cases. But there are two big cons:

• No any ducumentation now, just tests. See http://code.google.com/p/dataobjectsdot ... ectMapping

• Its configuration API will be changed in future. The code using current API is absolutely unreadable.

Finally, it must be a good idea to provide simplified API like this:

var mapping = new Mapping()
  .Map(typeof(PersonDto), typeof(AddressDto)) // Conventional mapping
  .Map<Customer>().To(CustomerDto) // Fluent mapping
    .With(c => c.Company.Name, dc => dc.CompanyName)
    .With(...)
  .Done();
mapper = new Mapper(mapping);
// mapper = new Mapper(typeof(PersonDto), typeof(AddressDto), ...) - shortcut for conventional mapping
// mapper = Mapper.Get<PersonDto>(typeof(OtderDto1), ...) - shortcut for getting default conventional mapper (must be cached). 
// Since they're thread safe, this should work well.

...
// Creating DTOs
var dtoGraph = mapper.Transform(entityGraph);

...
// Applying the changes
mapper.Compare(originalDtoGraph, newDtoGraph).Operations.Replay();

// Finally, we can implement simplified conversion to DTOs using default conventional mapper:
var personDto = Mapper.Transform<PersonDto>(person); // or using a shortcut for persistent objects: person.Transform<PersonDto>()

Unfortunately, this is only an example showing how this part could work. Current API is much less attractive...

Forgot to ask: what is the final goal of conversion to DTO in your case?

E.g. if you need this to mainly cache something (you said you don't want to modify the DTO), we may talk about caching API. It is also in plans, so getting any exact requirements would be great.

I thought pretty long on this. For now I recommend you to do not optimize for caching scenarios. We're planning to implement caching support in DataObjects.Net, and, when it's done, you'll get layered caches and declarative semantic for managing them; scenarios we're going to cover include as Entity, EntitySet and query result caching.

The only reason for postponing caching implementation was absence of real customer requests related to this.

In cases when caching API won't suit well, the following options will be available: 1) Simplified conversion API relying on O2O mapper: entity.TransformTo<entitydto>(), entity.ApplyChangesFrom<entitydto>(original, current). Must work well in almost all the cases except 2) 2) DisconnectedState. Good for implementing long-running transactions. Must be extended to allow explicit content inclusion / exclusion, and obviously, we must simplify its usage in web applications (currently it's pretty complex, especially in conjunction with SessionManager). That's what I'm going to do on the next week.

> So, I think the simplified conversion API should be the top priority.

Yes - we'd deefinitely deliver an open caching provider API first, + few actual providers (e.g. for ASP.NET cache).

> entity.TransformTo<entitydto>() will be even better if it can transform the prefetch object graphs too.

Specifying the boundaries of graph to transform is definitely a pretty complex problem. Agree, prefetch API might help here - I'll return back to this question when we'll start working on improvement of this feature.