Re: Decouple SQL queries from class in OOP design
- From: "Cristiano Sadun" <cristianosadun@xxxxxxxxxxx>
- Date: 10 Nov 2005 07:04:19 -0800
Well, it's not that you cannot put SQL in classes. Even if you put it
outside (in files, in a daabase), it's quite likely that things would
break if you change it in certain ways (in most ways) - so you pay in
additional complexity without gaining much - if anything at all.
What you want to do is to shields client classes from the
implementation details of querying. You do that by defining an
interface which exposes querying behaviour in a form which is
independent from SQL. Then you implement this interface in the most
efficient way - namely, classes that handle their own SQL.
These classes can in turn be defined so that certain parts are
configurable (say, the database schema, the name of the tables etc) but
the structure that is *fixed* at any point isn't. Beyond a certain
limit, attempting to configure everything becomes overdesign - since
you pay as much for changing configurations than for changing code, and
usually without all the checks and balances provided by the compiler
and (depending on opinion ;-) static type checks.
.
- References:
- Decouple SQL queries from class in OOP design
- From: Hongyu
- Decouple SQL queries from class in OOP design
- Prev by Date: Re: Small Cohesive Objects - Configuration
- Next by Date: Re: Small Cohesive Objects - Configuration
- Previous by thread: Re: Decouple SQL queries from class in OOP design
- Next by thread: Re: Decouple SQL queries from class in OOP design
- Index(es):
Relevant Pages
|
