Re: Application logic and Business logic

From: frebe (fredrik_bertilsson_at_passagen.se)
Date: 02/28/05 

Date: 28 Feb 2005 10:07:10 -0800

> The GUI or DB may not disappear. But put yourself back in the early
90s
> before the web was revealed to the unwashed masses. How great it was
for
> those of us with separated logic to easily and quickly front-end our
systems
> with HTML.

I spent (wasted) a number of years with developing "3-tier"
applications that did separate "business" logic from presentation
logic. The problem is that in the applications a worked with
(production control and human resource administration), 70% of the
logic was in the "thin" client. Switching from rich client to HTML
client still was a major task. And the price for this was a real code
bloat. Now I am using data-aware GUI components and is a much more
productive programmer.

> Would you rather your business logic be wrapped-up inside the
dumb-terminal
> code or that it be separated into its own layer?

It is impossible to have a client application with 0% "business logic".
But I agree that you should try to separate as much as possible of the
"business logic" from the client code.

> As far as databases are concerned it may not be that I'll change from
Oracle
> to Sybase, or SQL Server to DB2, but more likely that we'll need to
reorganize
> the database, move some fields, split some tables up, etc.,

Please give an example of a schema change you want to do, that will not
effect your "business logic" (or even presentation logic) too. A lot of
"business logic" is implemented in the database schema. The most common
schema changes is to add columns or tables, and doing this without
changing the rest of the application is a little bit pointless.

> and for the
> business layer to have hardwired itself to a specific table layout is
nearly
> as restrictive as mixing business and UI logic.
Why? Do you have some motivation for this?

> Better to treat the database as a huge object that hides its data
(table,
> rows, fields, organization, syntax, etc.) behind methods (stored
procedures)
> which are the only way to transact with it.
Using stored procedures will make you database vendor dependent. The
most important customer demand today is database independence. This
approach will also force you to write 1-10 stored procedures for every
table. This is a real code bloat. Besides, you will disable the
programmers to take real advantage of the functionality in a database.

Fredrik Bertilsson
http://butler.sourceforge.net

Relevant Pages

  • A Challenge
    ... My client is expecting me to perform miracles. ... I have been using space delimited to separate the fields and then doing ... - a database of words like Di, St., Del, O', or Le could be defined as ... the first column and second in second column, ...
    (microsoft.public.excel.programming)
  • Re: Huge database weighs heavily on small brain
    ... > My database has too many subforms on too many levels. ... > like to do is separate these Archive periods from the Main Form so they ... > database, or create a new database for the Archives, I must link them to ... > longer a SubForm) or match an existing one using the Client ID. ...
    (microsoft.public.access.forms)
  • Re: Can Access handle this configuration, or do I need SQL Server?
    ... >> a separate copy of the database for each user and then open this copy. ... > client app like TS so the client can view and control the front end that's ... > on the server or the server's local network. ...
    (microsoft.public.access.setupconfig)
  • Re: Can Access handle this configuration, or do I need SQL Server?
    ... >> a separate copy of the database for each user and then open this copy. ... > client app like TS so the client can view and control the front end that's ... > on the server or the server's local network. ...
    (microsoft.public.access.formscoding)
  • Re: Opinions needed about the best "Middleware suite" kbmMW vs. RODA
    ... kbmMW supports cross db in such way that all you need to do in your application is to set one property to switch to ... What one have to concentrate about is minimizing the amount of data moved from the app server to the client. ... C/S setup's usually have a quite active chatter going on between the client and the database, ...
    (borland.public.delphi.thirdpartytools.general)