I have some questions regarding your post on Mobile Objects. Like the reader who asked you that question, we too have decided on mobile objects to simplify the amount of code that needs to be duplicated between client and server. We don’t use RPC (i’ve been burnt with DCOM too many times to make that mistake again), so maybe none of the discussion applies to our architecture, but to be sure, I’d appreciate your advice.

Our client software is a thin client that persists no information itself. All information is retrieved from the server. Our domain model is light weight and uses the manager model to enforce business logic and persist information via respositories. All domain model classes are serializable and contain no logic of their own aside from basic validation. All objects implement custom serialization in order to allow for basic versioning.

The managers are implemented using interfaces, for which we’ve created an interface proxy on the client side. The client and server use exactly the same objects and the same manager interfaces. The only difference being that the implementation of the manager on the client directly proxies all calls to the server’s manager implementation. The client managers also implement caching to minimize unecessary round-trips. Where necessary, client managers can also be overriden to implement client specific validation or more intelligent caching.

The managers are rough grained as all calls are assumed to be remote. But as the domain objects are light weight, this is rarely an issue.

We’re convinced that this is a good architecture for our situation, but like your other reader, I’m now worried that there is some major pittfall that I’m just not seeing. The only real issue that we’re aware of is tight-coupling between our client and server, but in our environment this isn’t considered major.

We don’t use DTO’s nor really see the benefit in this situation. We often create 2 classes for each domain object. For instance we’d have a Customer object that contains only basic information that would be needed to display in a list. Then we’d have a descendant CustomerDetail object that would contain the detail like addresses etc. Our ICustomerManager would have a method like GetCustomers() that would return a List and another method GetCustomerDetail(int code) that would return a CustomerDetail object. In a way I suppose that is a DTO, but certainly not in the way that Martin Fowler describes using it.

So the question really is this:

* Is our architecture based on bad practises (violating the First Law of Distributed Object Design)?
* If it is, what would suggest doing in this kind of architecture to fix the issue?

BTW, I was going to try and contact you directly, but I must be blind, I can’t find anywhere to do so!