Re: Decouple SQL queries from class in OOP design

On 9 Nov 2005 17:35:50 -0800, Hongyu wrote:

> To my knowledge, in OOP design it's not good to mix SQL queries with
> application codes in classes, because it limits the usability of the
> classes and bound them to the local database schema. But I am not sure
> what the best way is to decouple them. The method that I am using right
> now is to create a hash to store all the SQL statements and prepare
> them in the main program, then I will pass this hash as a variable to
> all the classes that are going to use it. I am not sure whether there is
> any better design.

The answer may depend on what is SQL to you. Or more generally, what is the
role of DB in your design. Is it just an implementation detail of
persistence? Is it a legacy system?

Anyway, I guess it might be difficult to prepare statements without knowing
the objects they are going to work with. Then there is the issue of
transactions, connections, environments etc. So "hash" is probably
Transaction which refers to a Connection etc. You should also consider the
issue of life times. Some sort of GC might be required to ensure that
objects local to transactions don't outlive them. For my [admittedly
limited] purposes, I tend to use a persistence layer which hides DB away.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: access 2007 accountancy application
    ... subqueries are used within a query its not possible to do it all in design ... What I posted was the SQL of the query. ... FROM Transactions AS T2 ...
    (microsoft.public.access.gettingstarted)
  • Re: Application logic and Business logic
    ... The design patterns choosen was the ... Doing entire banking transactions in SQL, ... "The aim of science is not to open the door to infinite wisdom, ...
    (comp.object)
  • Re: SQL
    ... > If you design right, you can *shift* much behavior to being data and ... > SQL is close to being Turing Complete. ... It is a bad habit of yours. ... If you're seriously suggesting that CRUD applications are equal ...
    (comp.object)
  • Re: Object-oriented thinking in SQL context?
    ... away from arrays and other non-OO data structures associated ... SQL is constrained to 'trivial' arrays. ... Design: Logical Design", 4th edition. ... Something analogous happens with database design. ...
    (comp.databases.theory)
  • Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
    ... was good not to rely *entirely* on the ahsh algorithms. ... The point is that the current random.c design DOES NOT ... RELY on the security of the hash function. ... plaintext that's not one of the two. ...
    (Linux-Kernel)