RE: [Dunit-interest] Delphi XP Question

[Morris, C. <chr...@sn...>]

> Now here comes the complicated.  I now have a class that will 
> consist of a
> collection or a list or records from a database.  In the past 
> when I wasn't
> using classes I would just right my code (maybe from a button 
> click or a
> page control change) and open the ADO recordset which was 
> linked to a grid.
> Very simple and easy, but all the code is mixed with the 
> visual side.  
> 
> So I decide to write a class that can retrieve the recordset 
> among other
> things.  How the heck do I now tie this back to the client.  
> Do I actually
> pass back the whole dataset and then use a db aware 
> grid/control to display
> the data???   

Sure. Add the TDataSet to your class:

TMyClass = class(TObject)
private
  FDataSet: TDataSet;
public
  procedure GetClientOrders(ClientID: integer);

  property DataSet: TDataSet ...
end;

procedure TMyClass.SetupDataSet;
begin
  FDataSet := TQuery.Create(nil);
  ...
  // assign to database object, etc
end;

procedure TMyClass.GetClientOrders(ClientID: integer);
begin
  SetupDataSet;
  FDataSet.SQL := 'select * from orders where clientid = ' +
IntToStr(ClientID);
  FDataSet.Open;
  FDataSet.FetchAll; // if cached, whatever ...
end;

Easy to unit-test. Then from your GUI:

procedure TMyForm.OnGetClientOrdersButtonClick(...);
begin
  // this has no owner ... you'll need to store the instance 
  // somewhere so you can clean it up later, but that's a tangent
  // for the moment
  aMyClass := TMyClass.Create;
  aMyClass.GetClientOrders(StrToInt(edtClientID.Text));
  Self.OrdersDataSource.DataSet := aMyClass.DataSet;
end;


> This seems like I am breaking the whole object oriented
> approach.  

This is really breaking the RAD Graphic Design approach. It's still very
OOP. What you lose in ease of design and additional time coding the run-time
connection, you gain in ease of testing. To me, the trade-off is very
worthwhile. This is exactly the kind of thing that could make you
second-guess your descent into test first in the beginning, but once you've
amassed that flexible object-data layer that's 100% automatically tested,
it'll definitely be worth it.

> It also makes it difficult to move it to the web 
> in the future.

Should be as easy to go to the web, if not easier because you won't have
this data-retrieving logic living in a TForm. The TForm won't be used in the
web (unless you go the ActiveX control route, but that makes this point
moot). With TMyClass in a separate unit, anything can call it and use it ...
including a unit within an ISAPI .dll that turns the data in
aMyClass.Dataset into html, or whatever. ADO will do XML result sets, which
could be passed directly to the web via an XSL page. Piece of cake.

Chris