Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: <>
Date: 1 Jun 2006 05:47:40 -0700
Message-ID: <>

> It makes sense to embed SQL in the database code for the
> reasons you give, but not in the UI code. The UI is the most likely
> bit to change in the near future, as we respond to the prevailing
> tastes of the user community ("we want it
> GUI-based/browser-based/mobile-based/...") The database part OTOH may
> not need to change for a long time, provided it performs well and
> serves the UI well.

So, what is the gain in separating the SQL statements if the they can be regarded as constants?

> The interface between the UI and the database is
> at the level of business functions (e.g. "create an order", "produce
> bills for this month", etc.) and is typically an API.

The interface database between the UI and the database could be SQL statements (just look at sucessful LAMP applications out there), but it could also of course be functions/methods too. Every time you have a fragments of code that is likely to be called from multiple points in the application, you should do a function/method. But what is the point in a method like this:

function createOrder(id, customerid, deleiverydate) {

    insert into order values (id, customerid, deliverydate); }

Fredrik Bertilsson Received on Thu Jun 01 2006 - 14:47:40 CEST

Original text of this message