Disconnected record sets are nothing new and there's no reason to not use them other than the usual one(s) of "as long as it is appropriate in any particular case and there simply isn't enough information here to say whether it may be inappropriate in this one.  :)

One concern that may or may not be pertinent is that by directly exposing a component of your database layer it is effectively poking through the business layer and into the GUI layer.  Should you ever find yourself needing to abandon ADO in the future, your TADODataset cannot be replaced without impacting directly on the code in the business layer that works with it or the code in the GUI layer.

Mon, 4 Nov 2013 07:57

Hi all.

I am in the process of redeveloping an existing application that has reached the end of its ability to add stuff nicely without breaking other bits of the code. Admittedly best practice was not always followed J but its time to start version 2 of the app.

As part of this I am splitting stuff up into database, business and GUI layers – on paper at the moment, and a thought occurred to me. In .Net which I sometime work in, you uses datasets which are basically connectionless, and I wondered if anyone can think why I would not take a similar approach. I am using ADO, and at the moment I have a test procedure that calls a stored proc, then passes back a TADODataset which is not connected to any database, connectionless, then this procedure “does something” with the recordset, just looping it and printing stuff to a listbox at the moment.

When its done, it frees the object etc.

Can anyone see anything wrong with this approach? Or things I should be aware of etc?

 

Thanks, Jeremy

 

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with 
Subject: unsubscribe

Reply via email to