On Mobile Objects

It’s comments like this that give me pause and make me wonder if I should join this thread… Everyone’s gonna call me a moron, but I’m hoping to learn something here.

You are most definitely not a moron. :-)

We use mobile objects. (insert flame here)

No flames from me. No questions are dumb questions. Well actually, I’ve asked quite a few dumb questions, but this question is *definitely not* a dumb one.

I’ve never really understood (and this is simply my lack of experience/exposure) the whole DTO/separate objects on the client/server thing. It seems like extra work to me to have to copy all of the properties from one object to another, just because one object was used to cross the wire and another wasn’t. I’ve tried to get a grasp on this and haven’t ever been able to see a “complete” enough example to get why this is beneficial or good design. I’m sure there’s a reason – otherwise everyone wouldn’t be championing this particular pattern so frequently. I just wish I could see a complete example and “get it”.

It really depends on the scenario. In the “distributed object” context I was referring to, it was really a rail against Remoting style architecture. I can’t vouch for the product that Jeremy was describing in his message, but when I think of mobile objects, I think of distributed remoting designs.

In that particular style of design, you might create an object on the server, and get a proxy to it on the client. The client invokes methods which then actually run on the server.

The reason those styles of design are bad is that they tend to be very chatty with the traffic going across the network. You can imagine the amount of network traffic required when a property getter requires a roundtrip to the server. This ties directly into the Fallacies of Distributed Computing.
http://www.lostechies.com/blogs/evan_hoff/archive/2007/10/24/the-8-fallacies-of-distributed-computing.aspx

That style of design forgets that there is latency going across the network (among other things).

You might google RPC for more information if you want.

This is a slightly different topic from DTOs (Data Transfer Objects), however.

The purpose of DTOs is primarily to decouple layers in your application. They insulate your UI and Domain Model from one another. You typically see it used in conjunction with a Service Layer, where the service layer manages database transactions, manipulates the domain model, and manages the copying of data from the domain model to the dtos. Other people might actually use two layers to accomplish the same thing (see PoEAA for a good discussion).

Regarding the DTOs themselves:

As an example, start with a Customer class with Address1 and Address2 fields. Then build the Customer forms. At some point down the road you decide to factor the Address fields on the Customer, User, Supplier, and other entities to use a common class, the Address class. When you perform the refactoring, you also have to fix your UI code (Address1 and Address2 are not properties of Customer any more). That’s when the DTO would have stepped in to save the day. You could continue to have the Address1 and Address2 properties on the DTO while modifying the Customer class (and all the others). Your UI code would still bind to the Address1 and Address2 fields on the DTO. The DTO provides a level of abstraction between the layers.

Another example might be if you have a graph of objects with a complex relationship. You might have a Patient class with a collection of LabValue classes. Each of your LabValue classes references a LabTest (with the Lab name) class. This would be a key scenario to introduce a DTO. You don’t want your UI to have to know the complex relationships between these classes, and you don’t want to have to change your UI when/if the relationships change.

In short, use of the DTO pattern is optional (as is the service layer). It’s up to you whether you need it for your application or not. It has its benefits, but it also requires additional coding. I pass no judgement on people who don’t use it (I know a few people whom I greatly respect that don’t use it–even though they are using a full blown Domain Model).

Another slight variation would be on tiered applications where a client connects to a service somewhere (ie..a webservice running in the application tier). The DTO is actually quite handy in an application running a domain model behind a webservice. If you’ve ever dealt with ASMX webservices and the XmlSerializer, you know how picky the serializer can be. By decoupling the domain model objects from the WSDL, I gain two things:

First, if I return a DTO from my webservice (and not a domain object) I decouple the WSDL (the external system contract) from the webservice consumers. This may seem like a minor issue, unless you have webservice consumers who are out of your control (say, an application in another company). You don’t want to force them to recompile their app when you deploy a change in your domain model (you can replay the Customer scenario above with Address1 and Address2 to see what I mean). In code-first webservices, the DTO allows you to tightly control the WSDL schema.

Secondly (and more obvious), it allows you to use things like read-only properties and non-parameterless constructors in your domain model. The XmlSerializer is a bit fragile (for good reasons), so using the DTO allows me to loosen everything up for the serializer, while doing good class design for my actual domain objects (entities, etc).

In terms of WCF, DTOs make good Data Contracts whereas model objects don’t (for the above reasons). Versioning my entities with WCF stuff is a bad idea.

If anyone wants to send me an email sometime and have a chat about my application’s architecture, and explain some of this stuff to me, I’d appreciate it. I don’t know if I feel like having my ignorance taken to task in a public setting.

Kudos to you for asking. Now if only we could get more people asking questions. :-)

If anyone ever has a direct question for me, feel free to email me. It’s been giving me some topics to blog about of late.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

One Response to On Mobile Objects

  1. Russell says:

    Hi Evan,

    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!