"Petite Abeille" schrieb > > On Nov 11, 2010, at 8:30 PM, Olaf Schmidt wrote: > > > If such an "encapsulation of business-rules" is sitting in the > > DB itself - written in a proprietary "DB-dialect", then you > > cannot call such a thing a "business-layer" anymore. > > Nonsense :))
Of course... ;-) Nah, seriously... you know, how I meant that and what the context was ... *if* somebody decides to handle DB-Interaction (and his "set of business-rules") *not* directly "in the client" (or alternatively "in the DB-Server") - then he obviously does so, to decouple the Client-Application from the DB(-Backend) - allowing then (if done right), to "connect" this intermediate layer to different clientside Implementations (GUIs) - as well as different DB-Backends. Encapsulated in a Dll with the right interfaces, one can use it either serverside (e.g. behind a WebServer, to talk to Browser-Clients - delivering JSON- or XML- serialized Resultset-Content) - or behind a "real AppServer", to talk to "Fat Clients" (delivering Resultset-Content in a serialized "Object-Container" - as for example disconnected ADO-Recordsets on Windows, which are then understood by a large Set of languages, easily bindable with mostly only one line of code to a DataGrid or whatever GUI-Widget). Heck, you can put such a layer-Dll even at the clientside, to support a standalone App or alternatively a more Client/Server-like approach, capable to work against a different set of DB-engines even then (in the standalone App for example, against SQLite). ["Helsinki Declaration(s)"...] Cannot disagree more with these articles, sorry. >From my experience his main-assumption is just not true, that it is more difficult to develop such a layer with "modern languages or environments" - compared with a proprietary DB-dialect and some DB-specific enhancements or features. Perhaps you should give an example of a certain stored procedure (not too complex, to keep things more simple), describe what it does - and then compare it with the implementaion-code, done in a "normal language", which does use ODBC/JDBC/ADO or whatever and is using only "common SQL-statements", to achieve the same thing in a DB-engine-independent way? Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
