"Object Aware" GUI Controls

I have some business objects written in Delphi w开发者_如何学运维ith a custom scheme of database persistence which is finally working for my needs. Ok, great. Now it's time for GUI implementations. And here begins the problems.

How to bind my object to the GUI properly?

I cannot use Data Aware controls since I isolated all data access components into the ORM layer, so I start to write some "Object Aware" controls using the RTTI unit (I'm working with Delphi 2010), but I have the feeling I'm going the wrong way...

Some ideas on how to resolve this using only the VCL controls?

You have several patterns for linking ORM with User Interface.

See for instance the Model GUI Mediator pattern. In short, you write an observer which will reflect the ORM content into the UI components, and vice versa. This has been implemented for instance in the tiOpf framework for Delphi (this link has videos).

Another approach is to map your data at runtime: you design your form just like usual, then you fill the content in the OnShow event, then the "Save" or "OK" button will validate then save the content into the ORM record. This is what is done in the main Sample application of our framework. Easy to code in this simple sample, but could lead into spaghetti code if you have a lot of fields and validation to operate.

The last approach is to let your ORM creates the form.

In our framework, you can define some UI properties about each table, in a dedicated structure. Then a single unit will create a form with all editable fields of your ORM object. Links to other records will be displayed as a combo box, booleans as checkboxes, sets as radioboxes, and so on. Then the filtering (e.g. trim a text field from spaces on left or right side) and the validation (e.g. ensure that a field value is unique or a valid IP address) is handled not in the UI part, but in the business logic itself, i.e. the ORM.

IMHO it's mandatory to keep a true multi-tier architecture. That is, the UI has to rely mostly on the business logic. For instance, data validation must be part of the ORM, not of the UI. For instance, if you decide to add a web client to your Delphi client application, you won't have to code the validation another time: it will be common to both clients, separated from the UI implementation details.

What you could do (though I have no code samples) is use a combination of

• class helpers or interceptor classes
• binding interfaces for single domain objects and/or domain object lists

Class helpers have the disadvantage that they are not officially supported and you cannot add any fields to the class you are helping.

Interceptor classes are simply descendant classes with the same name as their ancestor:

uses
  stdctrls;

type
  TButton = class(stdctrls.TButton)
  end;

You can put interceptor classes in their own unit and use that whereever you want. Just make sure these units are included AFTER the standard unit, so your descendant is used at run time.

Benefit of interceptor classes:

• You can continue to design your UI using standard VCL or third party controls.
• You get all the advantages of descendants.
• You do not need to create or install your own controls.
• No need for special mapper classes or use of RTTI.
• Easily (well, relatively easily) integrated into a (DUnit-) testable user interface along the lines of Julian Bucknall's article on this in the (distinct) Delphi Magazine as referred to in this question/answer: Unit-testing mouse event handlers

Pseudo sample of interceptor control with binding interface / command interface:

uses
  stdctrls;

type
  ICommandAction = interface(IInterface)
    function IsEnabled: Boolean;
    procedure Execute;
    procedure Update;
  end;

  IBindSingle = interface(IInterface)
    function GetValueFromControl: string;
    procedure LoadValueIntoControl(const aValue: string);
  end;

  TButton = class(stdctrls.TButton, ICommandAction)
  protected
    function IsEnabled: Boolean;
    procedure Execute;
    procedure Update;
  end;

  TEdit = class(stdctrls.TEdit, IBindSingle)
    function GetValueFromControl: string;
    procedure LoadValueIntoControl(const aValue: string);
  end;

implementation could be along the lines of:

  function TButton.IsEnabled: Boolean;
  begin
    Result := Self.Enabled;
  end;

  procedure TButton.Execute;
  begin
    Self.Action.Execute;
  end;

  procedure TButton.Update;
  begin
    Self.Action.Update;
  end;

  function TEdit.GetValueFromControl: string;
  begin
    Result := Self.Text;
  end;

  procedure LoadValueIntoControl(const aValue: string);
  begin
    Self.Text := aValue;
  end;

My current customer have made their own "mapper" classes in the past (before I came). Their data objects have fields (which are objects), and you can map these fields to a control. I extended the framework by using a MVC-like approach:

edtTarraCode: TAdvEdit;

procedure TframTarraTab.InitMapping;
begin
  ...
  Mapper.AddMapping(edtTarraCode, Controller.DataModel.tarID);
  ...
end;

Per control a simple "mapping" class is created:

TMappingAdvEdit = class(TBaseEditMapping)
protected
  procedure InitControl; override;

  procedure AppData2Control; override;
  procedure Control2AppData; override;
end;

No rocket sience, and maybe better solutions are available in the mean time (this worked in D6 and lower :-) ) but it works good enough for the customer.

Btw: also a data object generator is used. So if a field changes in the database (for example tarra.tarid is changed into tareID) we get a compiler error because "tarid" does not longer exist. This works much better than "fixed string" mapping (runtime errors).

There's currently no way to do this using only VCL controls. I know that Lazarus has a set of RTTI-based data-aware controls; you might want to look at them for some basic ideas. But it's more difficult than you might think at first. For example, unlike a dataset, an object has no built-in signaling mechanism when its members' values change. Which means that unless your data-binding controls own the object completely and nothing else has access to it, it's possible for some other code to change some value and then that change doesn't get reflected in the UI.

I've heard various things from the Delphi team in the last few years about extending the object model or the RTTI model to allow for better data binding, but whatever that's about is still a few years out.

Take a look at EverClassy Dataset at http://www.inovativa.com.br. It may meet your needs. EverClassy Dataset is a Delphi dataset designed to be populated by objects instead records from a database system.

With this component you will have the chance to interoperate your domain objects with dataware componentes, what will give you great power to build your GUI.