Architecture Dilemma : Should Entities Travel All the Way to the UI?

I've been buried under Chapter 4 of my book for the last week or so -- you know, deadlines and stuff . Anyway, during this time I missed the onset of an interesting discussion among Andres, Udi, Jesse, Ayende, and Frans.

It all started when Andres posted that in Orcas there is no disconnected mode for Entity framework, Microsoft's version of O/R mappings. You can read the post, hopefully in the right order, at Andres, Udi, Andres, Jesse, Ayende Udi, Frans, Ayende).

I guess that coming late into the discussion there's not as much that hasn't been said by one of the parties, so I'll just mention that I share most of Udi's views on the matter and the way I see it Microsoft has too often given us enough rope to hang ourselves by providing ways for the inexperienced to easily build solutions that will make them suffer down the road (e.g. result in unsalable solutions, performance problems, etc.) so its good to see one occasion where it will be harder.

Anyway, what I do want to mention is a related architectural dilemma which is: When/if should Entities travel from the business layer(s) to the UI. The way I see it, this is the root cause for the above mentioned question of whether we need disconnected entities.

As I did with the previous dilemma (O/R mapping), this will be a multi-part discussion -- and I'll start by introducing the context.

Over the years we've seen a lot of architectures for distributed computing, starting with 2-tiers client/server with emphasis on the server side, 2-tiers with emphasis on the client side, 3-tiers, n-tiers, and SOA to name a few.

On the client side we have a range of client styles that can be used with the different architectures (not all styles are compatible with all server architectures) from Connected Systems (web and smart clients), applications that can tolerate communication failures which I'll call "Occasionally Disconnected Systems" and "Occasionally Connected Systems," which are meant to work off-line as part of their normal operations.

Moving Entities to the UI makes sense in some of the combinations, but doesn't make a lot of sense in some of the others -- which is what I'll start discussing in the next post on this series.

Posted by Arnon Rotem-Gal-Oz at 05:58 PM  Permalink