I completely agree with Graeme here.
Im past I mix OOP with RAD (DBWare components) and when I need to
maintain the code,
improve performace its give a lot more work than pure OOP.
Now with pure OOP is a lot more easy to maintain and improve the code.
After develop mixed code for 3 years, my opinion is:
"The cheaper is expensive when you have to maintain the code"
Graeme, can I use your comments for a FAQ in Jazz wiki?
[]s
Cesar Romero
Graeme Geldenhuys wrote:
On 1/13/07, Al Boldi <[EMAIL PROTECTED]> wrote:
OPF is really meant as a glue between OOP and the DBMS, to yield an
ODBMS
interface on the client side, for seamless OOP to DBMS integration.
This
may save you some coding, but only for the price of an additional
setup of
object properties, as OFP introduces yet another layer.
I'm not going to go into the whole Rapid Application Design vs Object
Persistence Framework argument again, so I'll give a summary of such a
discussion from long time ago.
Abstract
There is no question that the tools that come with Delphi/Lazarus can
be used to build a database application very, very quickly. The power
of the combination of the TDatabase, TQuery, TDataSource and TDBEdit
is incredible. The problem is that with every TDatabase or TQuery you
drop on a TDataModule, you have tied yourself more closely to the
specific database vendor (using vendor specific components). With
every TDBEdit added to a form, you have coupled yourself to that
particular field name in the database.
--------------------------------------
As the discussion on the list continued, most agreed that there was a
place for RAD and data aware controls in single tier file based
applications, or client server prototypes. Most of the experienced
client/server developers who contributed to the discussion agreed that
there was no room for RAD and data aware controls in sophisticated
client server applications.
Here are four problems with RAD and data aware controls.
1. *Tight coupling to the database design.* One of the biggest
problems with using RAD and data aware controls is that the database
layer is very tightly coupled to the presentation layer. Any change to
the database potentially means that changes must be made in many
places throughout the application. It is often hard to find where
these changes must be made as the link from the data aware controls in
the application to the database are made with published properties and
the object inspector. This means that the places to make changes can
not be found with Delphi's search facility. When data aware controls
are used, the amount of checking by the compiler of you code is
reduced. This means that some bugs may not be detected until run time,
or may not be detected at all until the user navigates down a path the
developer did not foresee. Developing a persistence framework allows
you to refer a data object's values by property name rather than by
using a DataSet's FieldByName method. This gives greater compile time
checking of the application and leads to simplified debugging.
2. *RAD and data aware controls create more network traffic.* It is
a simple exercise to drop a few data aware controls on a form, connect
them to a TDataSource, TQuery and TDatabase then load the DBMonitor
(C:\Program Files\Borland\Delphi4\Bin\sqlmon.exe) and to watch the
excess network traffic they create.
3. *Tight coupling to vendor specific database features.* At the
simplest level, all databases accept the same SQL syntax. For example
a simple, select * from customers will work for all the systems I have
come across. As you become more sophisticated with your SQL, you will
probably want to start using some special functions, a stored
procedure or perhaps an outer join, which will be implemented
differently by each database vendor. Data aware controls make it
difficult to build your application so it can swap database
seamlessly.
4. *Tight coupling to a data access API.* The BDE allows us to swap
aliases when you want to change databases, but what if you want to
switch from BDE data access, to ADO, IBObjects, Direct Oracle Access
(DOA), ClientDataSet or our own custom data format? (This is not the
fault of the data aware controls, but is still a problem with the
component-on-form style of developing.) A custom persistence framework
can be designed to eliminate this tight coupling of an application to
a data access API.
--------------------------------------
Sure, you can always extend, but what did you gain from using the OPF?
If the above wasn't enough...
1. The most powerful feature of the tiOPF has to be the Visitor
pattern. For us the
business, and the model of that business, is everything and the
Visitor pattern allows us to painlessly traverse the 'model' and
perform a specific action across a hierarchy of related entities. As a
result, it assists in allowing us to focus more on the business and
less on the technical code.
2. Speed of development - Its very, very easy to get a basic app up
and running.
3. Lets you build an object oriented application that can swap
databases with the flick of a command like a command line parameter or
a change of a compiler directive. Currently, there are persistence
layers for Interbase-IBX, Oracle-DOA, XML-MSDOM, XML-XMLLite,
Paradox-BDE, MSAccess-ADO, MSSQLServer-ADO, FireBird-FBLib,
FireBird-SqlDB, HTTP Proxy-Remote, CSV files and TAB files. So any of
my apps built with the tiOPF can use any of the above backend's
without code changes.
4. Family of abstract base classes for building a complex object model
with very little effort. The business object model can be applied to
an existing or new backend database.
5. Helper function which makes for an excellent programmers toolbox.
6. Model-GUI-Mediators for enabling any standard GUI component to
become Object Aware. There is a lot more standard non-DB Components
than DB Components.
7. 1400+ DUnit/fpcUnit tests to guarantee stability in the framework,
which got me into unit testing my own code as well. I now follow the
Test Driven Development process in my own code.
8. Cross platform between Linux and Windows.
Ok, you gained these helpers, but if they are specific to the OPF,
they cause
you to be locked into TiOPF.
If you look at the code of tiUtils.pas you will see over 90% of the
functions are not specific to the tiOPF framework. I use a lot of
those functions in small utility apps without using the tiOPF
framework.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
