Re: Decouple SQL queries from class in OOP design

Patrick May wrote:
> I don't understand the point of your question. Are you
> suggesting that there is no potential for reuse of business
> functionality across different applications?

Component reuse is a fiction rather than reality
http://jdj.sys-con.com/read/152251.htm

It is difficult to justify the need in complex component in a trivial
world of
"Fetch the data from the database, massage it, display it on the
screen"

> > > - Embedded SQL requires more than a simple SQL statement.
> > > The application must deal with database connections,
> > > transactions, cursors, etc. Encapsulating this overhead and
> > > allowing it to be reused across multiple applications reduces
> > > the complexity of each application and the opportunity for
> > > bugs to be introduced.
> >
> > If you have any difficulty opening database connection, or iterating
> > a cursor, you may think refreshing your programming skills. Those
> > are not the kind things that are worth abstracting.

I forgot transactions, that you mentioned. Are you aware that SQL
handles transactions as transparently as it possibly can? Are you
suggesting that you can raise application abstraction level to the
point when application programmer don't have to be aware of the
difference between optimistic and pessimistic locking?

> The application should focus on _why_ it needs particular
> functionality and _when_ to invoke that functionality. Mixing
> database access details and schema-specific logic in with application
> logic reduces maintainability. Further, duplicating that logic in
> multiple applications contributes further to maintenance problems and
> introduces more opportunities for bugs.

What maintainability? If I change the schema, does it affect the
connection? Nope. If I add a column to the table, the application would
still be happily iterate the cursor, and get all the required fields
from the record.

> > > - Encapsulating SQL in components or services that expose
> > > required functionality instead of the underlying database
> > > schema makes impact analysis much more straightforward and
> > > reliable. When SQL is embedded in applications across the
> > > enterprise, it becomes virtually impossible to determine the
> > > effect of any proposed change to the database schema.
> >
> > If the schema change is nontrivial (because just adding a column
> > wouldn't break anything), then you make backward compatible
> > views. Is this kind of obvious?
>
> And for the next change? And the next? Are you suggesting that
> adding an arbitrary number of new views with names like EMPLOYEE_V1,
> EMPLOYEE_V2, EMPLOYEE_AS_OF_20051122, etc. is better practice than
> encapsulating the business functionality required in one place? What
> about changes that are more complex than simple additions? Those
> views are going to start to affect performance.

You are constantly repeating the point about changing the schema, and
yet give no example of such a change. Once again, most schema changes
don't affect the application. Columns are never deleted from existing
tables. New columns and table addition won't affect any application.
The only significant change that could break the existing application
is a pretty serios schema reorganization.

The naming you use is completely wrong. I don't know how you name your
classes and methods, but it is possible to name the tables in a
meaningful way. If you have EMPLOYEE_V1, and EMPLOYEE_V2, then it is
very likely that they don't differ in a few extra columns which doesn't
justify introducing a new name at all.

.

Relevant Pages

  • Re: Reusing SQL data-related logic, replacing weird modules and improving Class::DBI
    ... capable of doing what I was suggesting, ... the answer is "yes and no." It does allow you to builder queries upon ... I might want to conditionally build a query ... we should consider important factors about the functionality: ...
    (comp.lang.perl.modules)
  • Re: Decouple SQL queries from class in OOP design
    ... There is no change to the functionality supported ... > by the database, but the schema changes. ... > Denormalization for performance, as noted above, will definitely ... serioulsly chllenge his SQL tuning abilities. ...
    (comp.object)
  • Re: Decouple SQL queries from class in OOP design
    ... There is no change to the functionality ... but the schema changes. ... >>> If they are using the same database schema, ... >> A particular schema is an implementation detail. ...
    (comp.object)
  • Re: Dataset without a database - editing the .cs file
    ... functionality you want to add, and on the scope of the project. ... > I see that I can create an .xsd file at VS.NET will create a corresponding ... > autogenerated from my schema to add some functionality. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: How do I script object creation?
    ... For those unfamiliar with the functionality, ... objects, across any schema, and SQLserver will automatically generate ... all DDL for creating the object (in the case of tables and indexes, ...
    (comp.databases.oracle.misc)