Business logic separated from GUI? 
Author Message
 Business logic separated from GUI?

Hi,

One thing that I'm frightened in delphi and it's two-way tools is that
it's easy to create a software where business logic is tied closely
to a GUI code. Of cource this is not the way to go in a most companies.

What is (might be) a proper way in Delphi to create a database
software where business logic is separated from GUI code as much
as possible?  I'd like to hear your ways to solve this problem. How
did you solve the problem in the implementation level when using Delphi
as a development environment?  

How about 3-tier architecure?  I know what it means in the conceptual
level, but how can it be achieved in the implementation level when
using Delphi? What piece of code and logic goes into a databases
and what goes to PAS units?

Regards,
 Mika



Sat, 08 May 1999 03:00:00 GMT  
 Business logic separated from GUI?


<snip>

: What is (might be) a proper way in Delphi to create a database
: software where business logic is separated from GUI code as much
: as possible?  I'd like to hear your ways to solve this problem. How
: did you solve the problem in the implementation level when using Delphi
: as a development environment?  

I wrote for every table own TTable descendant and added rules there.
(ie, TCustomerTable, TInvoiceTable, ...)

I don't know if it right but whenever I drop such table into form I am
sure that all rules are there and I haven't forget something.
Also there is only _one_ place to change code and it is easier to maintain
code. Also adding table's fields as properties gives very nice
shortcut to fields - besides using
tCustomers.FieldByName( 'Name').asString := 'Smith';
I just write
tCustomes.Name := 'Smith';

I have used three level drivation from TTable:

TTable -- TBaseTable -+- TBaseCustomerTable - TCustomerTable
                      +- TBaseInvoiceTable  - TInvoiceTable
...

TBaseTable contains
* user level security (who has access and who does not)
* generating keys
* confirmations "Save changes (y/n)"

TBaseXXXTable-s are generated by small prog and contain public properties
for each field.

TXXXTable contains hand-written business rules.
sometimes it is just TXXTable = class( TBaseXXXTable );
---

I don't know if TTable descendant is right solution. I think that some
business objects that are bound to table would be better way ie, have one
TBusinessTable that can use TBusinessObject which contains business rules.
Additionally there should be some formal way to decribe rules because
writing rules by hand is sometimes quite dedious.

tanel



Sat, 08 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:

> Hi,

> One thing that I'm frightened in Delphi and it's two-way tools is that
> it's easy to create a software where business logic is tied closely
> to a GUI code. Of cource this is not the way to go in a most companies.

> What is (might be) a proper way in Delphi to create a database
> software where business logic is separated from GUI code as much
> as possible?  I'd like to hear your ways to solve this problem. How
> did you solve the problem in the implementation level when using Delphi
> as a development environment?

> How about 3-tier architecure?  I know what it means in the conceptual
> level, but how can it be achieved in the implementation level when
> using Delphi? What piece of code and logic goes into a databases
> and what goes to PAS units?

> Regards,
>  Mika

Mika,

Easiest way to separate out the business rules from the GUI is to create
a unit that implements the business rules, but don't create a form for
it.  Then, create other units that implement the UI and make the BR unit
part of the USES clause.  Further, there are many 'business rules' that
DON'T need to be part of the database.  I'd only include in the DB those
stored procedures/triggers that directly affect how the db itself is
manipulated.  In other words, a function to do Double Declining Balance
Depreciation does NOT need to be part of the DB, nor should it be built
into a Form unit.  (Of course, Borland was nice enough to put this into
the Math.pas unit.)

HTH

Derek



Sat, 08 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:

> Easiest way to separate out the business rules from the GUI is to create
> a unit that implements the business rules, but don't create a form for
> it.  Then, create other units that implement the UI and make the BR unit
> part of the USES clause...

I'm interested in this, particularly since one of our upcoming projects
is
likely to need two entirely different form layouts to the same database
system, one using a touch screen.

I got the impression from Borland that Data Modules was their
recommended
approach (for Delphi 2).  Trouble is, I haven't seen much sample code
about
to illustrate implementation of business rules using these.

Suggestions anyone?
__________________________________________________________________
Grant Walker        Hobart, Tasmania         Ph: +613 62313083
Design Engineer     Australia                Fx: +613 62313086



Sun, 09 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:
> I'm interested in this, particularly since one of our upcoming projects
> is
> likely to need two entirely different form layouts to the same database
> system, one using a touch screen.

> I got the impression from Borland that Data Modules was their
> recommended
> approach (for Delphi 2).  Trouble is, I haven't seen much sample code
> about
> to illustrate implementation of business rules using these.

> Suggestions anyone?

Grant,

Data modules are used to tie the TTable, TQuery, Datasource and Database
objects into one non--runtime-visible unit.  I'd *STILL* put my business
rules in a regular unit that does not have a form associated with it.

Derek



Sun, 09 May 1999 03:00:00 GMT  
 Business logic separated from GUI?


Quote:
> One thing that I'm frightened in Delphi and it's two-way tools is that
> it's easy to create a software where business logic is tied closely
> to a GUI code. Of cource this is not the way to go in a most companies.

> What is (might be) a proper way in Delphi to create a database
> software where business logic is separated from GUI code as much
> as possible?  I'd like to hear your ways to solve this problem. How
> did you solve the problem in the implementation level when using Delphi
> as a development environment?  

We place all the non-visual data access components (TTable, TQuery,
TDataSource, ...) into Delphi 2 DataModules.  Business rules are
also created in the DataModules.   On the forms, we attempt to use
visual DB-aware components (TDBEdit, TDBGrids, ...) as much as possible.  
By following this procedure, you automatically separate the application's
domain from the front end.  This has worked well for us, eases maintainance,
and allows us to share the domain with many forms (views).

Ralph



Sun, 09 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:

> I got the impression from Borland that Data Modules was their
> recommended
> approach (for Delphi 2).  Trouble is, I haven't seen much sample code
> about
> to illustrate implementation of business rules using these.

I've been defining the data model objects in the data module unit, and
adding functions to create/retrieve 'em to the data module object.

--

http://www.midnightbeach.com/jon   Personal Pages
http://www.midnightbeach.com/jon/pubs Programming Publications
http://www.midnightbeach.com/hs             Home School Resource List



Sun, 09 May 1999 03:00:00 GMT  
 Business logic separated from GUI?


Quote:
>Hi,

>One thing that I'm frightened in Delphi and it's two-way tools is that
>it's easy to create a software where business logic is tied closely
>to a GUI code. Of cource this is not the way to go in a most companies.

>What is (might be) a proper way in Delphi to create a database
>software where business logic is separated from GUI code as much
>as possible?  I'd like to hear your ways to solve this problem. How
>did you solve the problem in the implementation level when using Delphi
>as a development environment?  

>How about 3-tier architecure?  I know what it means in the conceptual
>level, but how can it be achieved in the implementation level when
>using Delphi? What piece of code and logic goes into a databases
>and what goes to PAS units?

While you can use Delphi to create the kind of mess that is rampant in the VB
world you can also use it to separate the business logic from the interface.

John

Wake up and smell the Clintons!



Mon, 10 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:


> > One thing that I'm frightened in Delphi and it's two-way tools is that
> > it's easy to create a software where business logic is tied closely
> > to a GUI code. Of cource this is not the way to go in a most companies.

> > What is (might be) a proper way in Delphi to create a database
> > software where business logic is separated from GUI code as much
> > as possible?  I'd like to hear your ways to solve this problem. How
> > did you solve the problem in the implementation level when using Delphi
> > as a development environment?

> We place all the non-visual data access components (TTable, TQuery,
> TDataSource, ...) into Delphi 2 DataModules.  Business rules are
> also created in the DataModules.   On the forms, we attempt to use
> visual DB-aware components (TDBEdit, TDBGrids, ...) as much as possible.
> By following this procedure, you automatically separate the application's
> domain from the front end.  This has worked well for us, eases maintainance,
> and allows us to share the domain with many forms (views).

> Ralph

In the project I am currently working on we have tried to take this a
step further, and have created a 'business object' (which uses several
other custom objects), which interacts with the database. We use no DB
aware components at all, the forms interact instead with the B.O.
although there are plenty of things that will be done differently next
time, the approach has its merits.

Mickey



Mon, 10 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:

> In the project I am currently working on we have tried to take this a
> step further, and have created a 'business object' (which uses several
> other custom objects), which interacts with the database. We use no DB
> aware components at all, the forms interact instead with the B.O.
> although there are plenty of things that will be done differently next
> time, the approach has its merits.
> Mickey

If it won't cause you to let too much go I would be very interested to
hear what pitfalls you uncovered, or better yet, what your "next time"
list looks like.  

I'm prototyping a wee app that this plays into.

        Doug.
        Basis Applied Tech



Mon, 10 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:

> > I'm interested in this, particularly since one of our upcoming projects
> > is
> > likely to need two entirely different form layouts to the same database
> > system, one using a touch screen.

> > I got the impression from Borland that Data Modules was their
> > recommended
> > approach (for Delphi 2).  Trouble is, I haven't seen much sample code
> > about
> > to illustrate implementation of business rules using these.

> > Suggestions anyone?

> Grant,

> Data modules are used to tie the TTable, TQuery, Datasource and Database
> objects into one non--runtime-visible unit.  I'd *STILL* put my business
> rules in a regular unit that does not have a form associated with it.

> Derek

Derek,

The Data Modules are a non-form, non-visual unit.  The only form-like
code is for design time only and the compiler strips that out at compile
time.

Mike



Mon, 10 May 1999 03:00:00 GMT  
 Business logic separated from GUI?



Quote:


>>Hi,

>>One thing that I'm frightened in Delphi and it's two-way tools is that
>>it's easy to create a software where business logic is tied closely
>>to a GUI code. Of cource this is not the way to go in a most companies.

People coming to Delphi from other environments occasionally try writing
their code this way, and end up with some of the most bizarre-looking
workarounds.  Then they find out 'the Delphi way' to do it.

Quote:
>>What is (might be) a proper way in Delphi to create a database
>>software where business logic is separated from GUI code as much
>>as possible?  I'd like to hear your ways to solve this problem. How
>>did you solve the problem in the implementation level when using Delphi
>>as a development environment?  
>>How about 3-tier architecure?  I know what it means in the conceptual
>>level, but how can it be achieved in the implementation level when
>>using Delphi? What piece of code and logic goes into a databases
>>and what goes to PAS units?

The "tied to the GUI" problem was mostly an apparent one, and most visible
in Delphi 1.0.  The business rules are typically hooked to the events in a
TTable or TQuery object, which is placed on the form as a NON-visual
component.  The limitation was that in the design-time interface, you
couldn't hook up a data control (a TDBEdit) to a datasource in a different
unit (module), or a datasource to a dataset (table or query) in a
different unit.

If you decided to forgo doing it 'visually', though, it was quite easy to
code the datasources and datasets into units of their own.  Alternatively,
you could derive new table or query classes and override the default
behavior to your own tastes.

Even with all the items in one form, Delphi 1 (and 2) uses a three-tier
structure.  You can hook up three data controls to the same datasource,
and hook that datasource to a table - you can then control what happens to
your data in the table's events.  For example, any time a new record is
needed, you can set fields in the tables OnNewRecord.  In contrast, the
data control TDBEdit can do no such thing with your data, and is
restricted to being able to handle the GUI aspects (mouse presses, drag &
drop).

In Delphi 2.0, they upped the abilities of the design-time environment by
allowing a "non-visual form", called a data module, which can contain all
manners of non-visual components.  In this way, you can set up your data
source and data sets in a data module, and hook up your controls (data
grids, edit boxes...) to the data source in that data module.

Perhaps I'm explaining too much, but I hope I've convinced you that Delphi
isn't so simplistic as seems at first glance :)



Tue, 11 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

The prior suggestions are great examples of keeping the business stuff
apart from the GUI.  I'm involved in a project with a Delphi 2 front end
for all GUI stuff and portable COBOL modules (yikes) that will run single
business transactions on workstations and huge batch routines on a
mainframe.  We would like to spread the CPU cycles evenly between our
remote systems and the big iron, and one way to do this was to have
business logic split apart into a language that supports compilers on both
platforms (plus we have a megaton of COBOL code and programming skills).
In order to determine just how flexible and portable you must be, you
really have to look at those long term company plans and get there before
they ask or demand it.  We're playing catch-up because we got a late start
on these PC things.  Is that Internet ever gonna catch on? :)

--
Chuck

Read original science fiction and fantasy works!
See http://moose.erie.net/~mudsox
"If you wish to be a writer, write."

Quote:
> > We place all the non-visual data access components (TTable, TQuery,
> > TDataSource, ...) into Delphi 2 DataModules.  Business rules are
> > also created in the DataModules.   On the forms, we attempt to use
> > visual DB-aware components (TDBEdit, TDBGrids, ...) as much as

possible.
Quote:
> In the project I am currently working on we have tried to take this a
> step further, and have created a 'business object' (which uses several
> other custom objects), which interacts with the database. We use no DB
> aware components at all, the forms interact instead with the B.O.
> although there are plenty of things that will be done differently next
> time, the approach has its merits.



Wed, 12 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

Quote:

> In the project I am currently working on we have tried to take this a
> step further, and have created a 'business object' (which uses several
> other custom objects), which interacts with the database. We use no DB
> aware components at all, the forms interact instead with the B.O.
> although there are plenty of things that will be done differently next
> time, the approach has its merits.

I am currently working on a project were we also use the 'business
object' approach according to 'Peter Coad'. We have developed an library
which supports mapping the business object to an relational database. Om
the GUI side we developed 'business object' aware components. The
mapping of objects to an relational database is not easy when the
business object classes must support inheritance, and object relations
(tree structures and child relations). There are also problems as how to
identify an object in the database. We have used a single object id
string.

Now i am looking for a ODBMS which can be easily integrated with Delphi.
Has anyone expierence on this matter ?



Thu, 13 May 1999 03:00:00 GMT  
 Business logic separated from GUI?

You need a 3 Tier architecture:

     - To enable business objects to be defined.
     - To enable business objects to be reused.
     - To enable application functionality to scale.

So what is a business object? It is an abstraction in the world being
proposed in your object model. It has rules of behavior and ways that
it interacts with the other objects in your model independently of how
it is presented in the GUI (very often there are multiple way, or
views presented) and of how it is stored in the DBMS.

Business objects enable reuse in the many situations were the GUI is
not the same (such as a different view) and the persistence is not the
same (memory/desktop/server/replicated/distributed/interchanged).

In COM and CORBA, business objects are large grained and might
traverse several tables, such as an invoice consisting of Master and
Detail records. In C++ and OP, the potential level of reuse is much
smaller, such as a Zip Code, Telephone Number or Social Security
Number (in the USA); these are small grained objects. Whether you want
small, large or both depends on your business requirements.

There are many ways to package these into Delphi. The one we are using
puts each small grained object into a TDataModule and builds up to the
large grained object by "has a" references. We wrote some simple
components to make it easy to build these in a standard way. We used
TDataModules because they are lightweight, they can be easily created
and managed in the IDE, they can be stored in the repository and
inherited from with the standard Delphi IDE New... expert.

We did not use the component palette for these objects because we have
many people working on these modules; managing complib was impossible
when many people needed to make changes if we stored them as
components. The object repository seemed to fit this better.

Leo



Quote:
>Hi,

>One thing that I'm frightened in Delphi and it's two-way tools is that
>it's easy to create a software where business logic is tied closely
>to a GUI code. Of cource this is not the way to go in a most companies.

>What is (might be) a proper way in Delphi to create a database
>software where business logic is separated from GUI code as much
>as possible?  I'd like to hear your ways to solve this problem. How
>did you solve the problem in the implementation level when using Delphi
>as a development environment?  

>How about 3-tier architecure?  I know what it means in the conceptual
>level, but how can it be achieved in the implementation level when
>using Delphi? What piece of code and logic goes into a databases
>and what goes to PAS units?

>Regards,
> Mika



Mon, 17 May 1999 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Question re: Dynamic business logic in database app.

2. Logic Question re: SQL

3. Logic Process: DataSentry/SelfCheck

4. Confused by logic - seeking some inspiration

5. random function and logic

6. Graphical Logic Mapping

7. Code logic question...

8. TechTips: Using table-driven logic

9. Exception logic no longer works

10. Separate colors for each TStringGrid cell

11. Read an external TEXT files and store info in 2 Separate ARRAYS

12. Input Statement that uses 2 separate chars.

 

 
Powered by phpBB® Forum Software