Re: [TFUI] Understanding the Representation Layer

xelcury wrote:


> I'm trying to understand the concept of a "Representation Layer"
> better. In the process of asking my question, I'm going to expose how
> much I don't know about a large assortment of things. Please bear with
> me. So, here we go.

I thought others would have tried this one by now. A "Representation Layer"
is any layer that translates between two formats. Mike Feathers's paper The
Humble Dialog Box has been most influential, but there's two simple rules:
Make the GUI Layer as thin as possible, and exclude from the Representation
Layer any GUI Toolkit identifier.

> Suppose we're building a database application for a veterinarian
> office. The database tracks pets (and their owners and appointments
> and whatnot). The project might be split into layers:
>
> 1) We have the data access layer. This is comprised of classes that
> retrieve and save data to a database, say a Microsoft Access database.
>
> 2) Then we have the business object layer. This is comprised of
> classes that give us an easy, object-oriented way of dealing with data
> from the database. Here is one of our classes:
>
> Pet
> ---
> Properties: Name, Id, Species, HairColor, BirthDate, etc.
> Methods: Save, LoadFromID
>
> The business object layer can do data validation. For example, say
> HairColor is never allowed to be set to "orange" if the Species is set
> to "ferret". The Pet object can throw an exception if you try to set
> HairColor to "orange" if the Species was already set to "ferret". The
> gui is expected to deal with that exception in an intelligent way.
>
> 3) Next we have our gui -- the forms that the users see. Here is one
> of these classes:
>
> PetForm
> -------
> Controls on the form: textboxPetName, textboxId, comboboxSpecies,
> comboboxHairColor, datepickerBirthDate, etc.
>
> The "non-humble" way of doing things is to somehow bind the controls
> in PetForm to the related properties of a Pet object. So in the
> constructor for PetForm, we might have...
>
> Pet currentPet = New Pet();
> Bind(textboxPetName, currentPet.Name);
> Bind(textboxId, currentPet.Id);
> Bind(comboboxSpecies, currentPet.Species);
> Bind(comboboxHairColor, currentPet.HairColor);
> currentPet.LoadFromID(petID);
>
> 4) So, we come to the "representation layer".
>
> I understand that it is meant to fall between the gui and the business
> objects. We add a new class:
>
> PetFormRepresentation
> ----------------------
> Properties: TextBoxRepresentativePetName,
> ComboBoxRepresentativeSpecies, etc
>
> A TextBoxRepresentative is an object that represents a TextBox, except
> it never draws anything on the screen. It has a "Text" property just
> like a TextBox, and all the same events.
>
> Somehow TextBoxRepresentativePetName in PetFormRepresentation gets
> bound to textboxPetName in PetForm. And somehow PetFormRepresentation
> is in turn bound to a Pet object.
>
> How far off is that?

The missing link here is the Observer Pattern (from /Design Patterns/).

However, there's nothing "wrong" with using your GUI Toolkit's data binding
system, if you want to go that way. Of course it supplies vendor lockin an
an added benefit. I suspect /Domain Driven Development/ by Eric Evans covers
this in a sub-chapter called "Smart UI AntiPattern". Just paint the freaking
form, and wire all the controls up. You save a lot of time going down one
vendor's specific way, and you can use that time to then seek a better
situation.

To bind controls to data, you need GUI events to turn into data layer
events. So make data objects Observe GUI controls. The Observer Pattern
exploits Dependency Inversion Principle, so the data objects needn't touch
GUI controls, only their representations. Then, when the data objects
change, the GUI controls observe them. Those links are what the "data bound
control" provided.

The next step up from the Observer Pattern is Model View Controller.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/