Simple pattern for representing a view of a domain object?

[Karl Seguin]

This is something I've tried to solve a number of different ways, wanted
people's opinion on how they solve it.

I have a class, say users, which has a bunch of properties/methods. Problem
is I want to make available only a subset of this information, say I want to
have a list of "online users" which only makes use of the username and id.

Problem is, I don't want to have to load the entire object. In a sense, I
want to create a view of the object with only certain properties exposed. I
don't want to use lazy loading. I don't want to reuse my user class as is
and only partially load it, because that would result in weird behaviour
(ie, the "FullName" property is exposed, but doesn't work).

One of the ways I've handled this is to use a quasi-proxy. Something like
UserView which is composed of a User object. In this case the User object
is only partially loaded (via some specific internal calls to dal). That
isn't a problem because that's hidden from the consumer. The UserView class
doesn't expose the property of the User class which won't be loaded, so
there's no confusion.

I've also done the inverse. Where my User class would be composed of the
UserView class. This to me is a more tranditional form of composition, but
it doesn't fit as well with this "view" way that I'm thinking.

Not too crazy about the word view for XXXView either

Anyways, anyone doing something better than that?

karl

 

[KJ]

Hello Karl,

Sounds like you got a lot of all the bases covered. But one thing you
didn't mention was the use of interfaces.

Your "user" class could implement multiple interfaces, and the
consumers of it would thus only consume it as an instance of one of
those interfaces (i.e., as the interface appropriate to the context).

In this way, casted to interface A, the consumer of "user" only has
access to the props/methods listed in A. "User" thus takes on multiple
identities.

Add a special set of "initialize" methods to the code, each
initializing the props corresponding to one of the interfaces. In this
way, you can lazy-instantiate only the props corresponding to the
required interface. This type of setup might also require an
intermediary class that hands out the appropriately casted (to the
interface) versions of the object to the consumer (something like a
factory).

I would also consider when taking approaches such as this that you make
sure that any programmers who take over this code know what's going on,
since it's probably going to be somewhat on the non-standard side.

It might be easier just to create multiple classes, since that is
actually the net effect of such behavior, except that that is much more
understandable to the end user than these other interesting
machinations.

p.s. Another NG useful for such discussions is comp.object

-KJ