> > Actually, where I am right now, we have someone specializing
<ADO snippage>
> > certainly not thinner if using client side cursors.
>
> Hmmm ... doesn't sound like a very thin solution to me....
OK, fine - it may not fit your definition of "thin" (I'll give mine later,
which are just as 'valid' (or not :) ) as yours), but IMO, and HTML front
end does not come even close to fitting the definition of RAD, which for me
would be much more important.
Here's my current ideas of "thin"
1. Browser based (thin but with no RAD, not if you want it to look good) OR
2. EXE - single .exe, maybe a few unregistered DLL's, packaged up in a way
that the user doesn't need to do anything to install/update - ie, a .cab,
NOT an installshield install (bloatware to install bloatware).
3. NO DB libraries on the client. PERIOD. MIDAS/CORBA/DCOM?/HTTP transport.
4. No setup - this is not as stupid as it sounds, but how many apps do YOU
use (or worse yet, write) that dont have intelligent defaults!!!
5. Logic resides in a middle tier (webserver/WebHUB/CORBA/MIDAS/etc etc),
display logic is in the client.
If you want to see a good example of this (kinda), look at:
http://pages.infinit.net/kaufman/Index.htm
Kaufmann Mail Warrior. Single .exe, 600K or so. About the best email app
around, I think - toasts netscape and outlook express in basic features
(only thing missing is IMAP for me - I dont use 99% of the other functions
of NS or OE)
Semi-thin:
1. The mid tier can/does run on the client. Only any use for mobile people
OR
2. MIDAS if you dont get your hands to dirty - ie, the client has the
processing logic, business logic etc, and just uses the NTIER method to get
data from the DB (hence no DB drivers, but a lot of business logic)
FAT:
1. DB drivers on the client (BDE, ADO, ETC)
2. Client talks to the DB directly, and contains all of the business logic.
As I said, you may think these are arse. Your entitled to that opinion :)
> That sounds like a sweeping statement to me.
>
> Data controls are good for the quick phone book type apps, but when you
want
> to do something more sophisticated, their limitations get in the way.
Case
> in point is the TDBGrid - it causes all sorts of locks to be placed,
because
> it keeps an open cursor. If you must use it, better to select your data
to
> a temporary table, and display the table - there are all sorts of other
> gotchas using data aware controls.
Problem is, the grid metaphore - esecially for editing - is not a good one,
except for getting data to the user in a quick and dirty manner.
> Its called OrderWare - no data controls, just a web application thats all
> :).
... and the app which I'm writing, which never touches the DB backend - it
gets everything as objects and structures from the middle tier - not a DB
driver or unit in sight.
> Using data controls encourage the practise of mixing your business rules
> with your UI. This makes the code difficult to reuse, port and maintain.
Definatly agree with this.
> That is my main gripe about them. Far better to create a data model and
> have your controls operate on the data model (not on datasets). You can
> then cleanly partition your code out into layers, eg. db access, storage,
> rules, UI.
Better idea, tho a fair bit of work, is to abstract your DB out into
objects - have the object handle load, save, insert etc into the DB, and
program the UI/front end to that Object model. Then, you dont have to care
if your objects are local (fat), or remote (thin) - the code is pretty much
the same, just the implementation of, say "TCustomer = class(TObjPersistant,
ICustomer)" that changes.
IMO, naturally.
:)
N
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
