No, we won't add this. The possibility to marshal them by ref was usually leading to chatty client-server interaction. Of course this worked, but you should do a lot to make this work well, i.e. in general, people were following this path:

• Get working, but chatty (=slow) interface from scratch

• Optimize it to make it less chatty - by providing services returning Offlines, and so on.

Now we're going to propose better pattern: we won't support MBRs (we can, by this will just confuse the people), but it will be possible to use Sync for any Domain. Sync is much less chatty by its nature (i.e. the smallest unit of information it delivers is the whole entity state, rather than e.g. single property; normally it will deliver the whole query results). Internally it will rely on a WCF service shared by master Domain, so in fact, Sync makes remote master Domain looking as if it would be marshaled by reference, but internally it will work as stateless SOA service.

So basically, working with sync means:

• Client get the server side state in bulks

• Client send the updates to server in bulks as well - any client-to-server update is issued by an explicit command on the client. Until this command is issued, all the changes (either top-level method calls or state changes) are gathered by Atomicity framework and applied only to the local database (cache) on the client. Our IMDB is implemented exactly for this purpose, although you can use any other database we support to act as such a cache.

Both these features imply you get almost ideal client-server interaction right from scratch. Moreover, you get almost the same result: you use absolutely the same entities on server and client, almost like with MBRs.