You are correct that with a well designed middle layer you may not need
to write any SQL for applications. I am partial to Hibernate, myself.

However, there are times where SP's and triggers do make sense, and an
ORM is an unnecessary or even undesirable layer.

The key is to use the right hammer for the job.

On Sat, 2005-08-20 at 21:07 +0200, Thomas Tomiczek wrote:
> Well, not wanting to go at all into an architecture discussion, but let
> me tell you tat I am one person thinking your arguments are not well
> thought out.
>
> Let me explain that in the last year and a half, for example, I have
> been writing and architecting a CMS that works against SQL Server,
> Oracle, MS Access and soon Firebird (Oracle is a LITTLe feature limited
> at the moment).
>
> During this project, which consists of more than 200 tables and roughly
> 250 or so business classes we have written
>
> ZERO
>
> Sql at all.
>
> There is not a single line of SQL in the whole application. Nada. Zero.
> On top of this (exception: oracle, firebird I am working on it) we are
> not only generating all queries and db operations, but also all DDL -
> database schema creation AND maintenance are fully automated.
>
> We only did this because so far we have been able to offset any and all
> performance issues through the use of a data access layer caching
> mechanism (which, especially when an object loads data from multiple
> tables, can even speed up the whole thing and dake load from the
> database).
>
> On top, the program team spent exactly
>
> ZERO
>
> Time on maintaining a data access layer, as data access is 100%
> automated under the object model by means of a middleware (that another
> team programs, but it is a product).
>
> Now,
>
> Given that SP's and data access are simply not existing - and thus there
> is no maintenance issue at all over the whole application, do you not
> agree that such an approach is way MORE well structure, thought over and
> consisten (and thouroughly tested) than yours? Oh, performance is more
> than satisfying.
>
> And before we made this middleware, we used a simpler one that hard
> hardcoded SQL statements - in ONE configuration file. You see, "not
> using SP's and using dynamic SQL" is by no means identical to "being an
> idiot and scattering your SQL over the whole project". There IS a ground
> for people using what looks like dynamic SQL to the database, but using
> a repository like mechanism (propably with a code generator for strong
> typed usage classes) to centralize SQL code on ONE location.
>
> Let me add that our fully automated configured data layer allows dynamic
> queries (strong typed, compile time checking) in a db independent form,
> and performs a lot of things that most programmers do not even dream of
> (like pretty advanced caching).
>
> Good programming is about eliminating unnessary superflous layers, not
> about making up justifications for them.
>
> What is the book you talk about, btw.?
>
> Thomas Tomiczek
>
> > -----Original Message-----
> > From: firebird-support@yahoogroups.com
> > [mailto:firebird-support@yahoogroups.com] On Behalf Of constantijnw
> > Sent: Samstag, 20. August 2005 20:59
> > To: firebird-support@yahoogroups.com
> > Subject: Re: [firebird-support] Design advice
> >
> > Helen Borrie wrote:
> >
> > > >I'm developing a commercial application that uses Firebird. At the
> > > >moment I have all my queries coded in stored procedures.
> > >
> > > This is extremely unnecessary.
> > >
> > Helen, why do people buy your book? I think most do because
> > you present scattered knowledge about Firebird in a well
> > thought over, structured and consistent way. Also you clarify
> > interdependencies between pieces of knowledge. It makes your
> > book more valuable than just a bunch of articles.
> > I prefer using stored procedures for accessing data just for the same
> > reason: well thought over, structured, consistent and
> > thorough tested mature code accessing data, instead of
> > dynamic queries scattered all over the place in all flavours
> > imaginable.
> > At first I was also very annoyed about those dependencies,
> > when changing a table field for instance. But now I find it a
> > big advantage that I can have I clear picture of what my
> > field change implies for the other logic used.
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > --------------------~--> <font face=arial size=-1><a
> > href="http://us.ard.yahoo.com/SIG=12h3vp83u/M=362335.6886445.7
> 839731.1510227/D=groups/S=1705115386:TM/Y=YAHOO/EXP=>
> 1124571544/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforg
> ood.org/topics/education/digitaldivide/?>
> source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/">In low
> > income neighborhoods, 84% do not own computers. At Network
> > for Good, help bridge the Digital Divide!</a>.</font>
> > --------------------------------------------------------------
> > ------~->
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Visit http://firebird.sourceforge.net and click the Resources
> > item on the main (top) menu. Try Knowledgebase and FAQ links !
> >
> > Also search the knowledgebases at http://www.ibphoenix.com
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>