Re: Decouple SQL queries from class in OOP design

"frebe" <fredrik_bertilsson@xxxxxxxxxxx> writes:
> > > In a god architecture, the database is owned by the application.
> > That absolute assertion is incorrect. Many systems that
> > provide significant, measurable business value are based on
> > architectures that include an enterprise or otherwise shared
> > database.
>
> Of course there are existing applications that uses many different
> architectures and still provides measurable business value. But we
> are talking about how to develop new applications, right?

Even if we limit the scope of the discussion to new applications,
there are still environments in which databases are shared by multiple
applications. New applications must deal with this reality.

> I think most architects agree that not every enterprise application
> should access every database directly.

We seem to be in partial agreement. I would go further and say
that all but trivial CRUD applications should be decoupled from the
schemas of any databases used.

> If application A want to access data from the database belonging to
> application B, application A has to interact with application B in
> some other way but directly access the database belonging to
> application B.

Again, not all databases have a single owner. Shared and
enterprise databases are quite common.

> > Database schemas change for a wide variety of reasons, including
> > support of new applications, support of modifications to existing
> > applications,
>
> As I pointed out before, new tables or columns will not break any
> existing application. But I would like to see an example of some
> other kind of schema change that would be possible to encapsulate in
> the persistence layer.

Denormalization for performance is a change I've seen on more
than one occasion. There is no change to the functionality supported
by the database, but the schema changes. If the application is
coupled to the schema, it too would need to change for no other reason
than the coupling.

> If you remove tables or columns, I can guarantee you that you have
> to rewrite your business object model too.

Not necessarily. If the new schema provides the same information
in a different way, only the implementation of the component or
service providing the business functionality need change.
Applications that are clients of that functionality are insulated.

> > and optimizations made by DBAs
>
> Changes in indexes, caches, etc will not break any existing SQL
> statemenets.

Denormalization for performance, as noted above, will definitely
break existing SQL. DBAs may also change the schema to support other
applications, for example by moving some columns from one table to a
new table in order to change a 1:1 relationship to a 1:M. Such
changes are not uncommon in large integrated systems.

> > Because SQL embedded in one application is not reusable in
> > another.
>
> If they are using the same database schema, it is obviously
> reusable.

Not unless you consider copy-and-paste to be reuse. If you are
suggesting instead that one application expose the functionality that
is implemented internally as embedded SQL then we seem to be agreeing
that the embedded SQL should be encapsulated and exposed as a service.

> > Decoupling the provision of that functionality from the details of
> > how it is implemented allows the same functionality to be provided
> > by a wide variety of different underlying implementations.
>
> A database schema is not an implementation. It is an interface. The
> RDBMS is an implementation. By using ANSI SQL, you decouple the
> application from any specific implementation.

A particular schema is an implementation detail. The same
functionality can be supported by a variety of schemas, more than one
of which can be in third normal form. Applications that depend on
functionality rather than schemas are more resilient to change than
those that are coupled to the implementation represented by one
particular schema.

> > Are you seriously suggesting that tightly coupling an application
> > to a database schema is good practice?
>
> Of course. Unnecessary decoupling will only cause you a code bloat.

I never suggested "unnecessary" decoupling. For simple CRUD and
reporting applications, direct use of SQL is probably a good choice.

> The database schema implements a lot of business logic, and the
> database schema only change when the business rules change.

That is simply not the case. I've provided a few examples of the
types of schema changes that occur in real systems. Changes to
business rules are far from the only reason for schema changes.
Anyone architecting a system of even moderate complexity must
recognize that such changes can impact the stability and resiliency of
components that use persistent information and address the risk
accordingly.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, CORBA, UML)
.

Relevant Pages

  • Re: polymorphism (was: Poly Couples)
    ... but this is not really "business software"... ... Most of such applications are built as a combination of ... database with flat files or a different RDBMS vendor?" ... couldn't care less if I do it in using structured programming or OOP ...
    (comp.object)
  • Re: Database abstraction layers (summary)
    ... RAD applications in MS-Access. ... the main reasons I began developing in PHP is that it is a total PITA ... Now I'm trying to do the same with the database. ... Metabase can take database schema definitions in a RDBMS independent XML ...
    (comp.lang.php)
  • Re: OOP/OOD Philosophy
    ... Lets say I want to change the business logic so different resources can ... and change in the code that do the checking and schema presentation. ... Claiming that I can have whatever database schema I want is just ... Coupling to a data ...
    (comp.object)
  • Re: Newbie object design questions
    ... >> Business Entity from the actual structure of the database and the ... bunch of applications blow up because they ... database in the same way that the business thinks of them. ... tables storing information about one business entity). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [Info-Ingres] String Manipulations
    ... and business rule enforcement. ... ensure that all the applications conform to the same conceptual model by ... testing them with reference to the model in the database. ... and that data *has* to conform to the conceptual model, ...
    (comp.databases.ingres)