Re: Application logic and Business logic

From: Alfredo Novoa (alfredo_novoa_at_hotmail.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 19:35:40 +0100

On 28 Feb 2005 10:07:10 -0800, "frebe"
<fredrik_bertilsson@passagen.se> wrote:

>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.

So you had 70% of application logic and 30% of business logic.

>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.

Indeed, HTML clients are a giant backwards step.

>It is impossible to have a client application with 0% "business logic".

Why?

I don't see any reason, and such applications exist.

>But I agree that you should try to separate as much as possible of the
>"business logic" from the client code.

And it means to eliminate the 100% of the business logic from the
applications.

>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 database design is a way to declare business logic. If you change
the database design you are changing the declared business logic. But
it is easy to imagine changes in the database design that does not
affect to the presentation logic. For instance to remove a constraint
or to replace a table by a view.

>Using stored procedures will make you database vendor dependent.

No, that will make you DBMS vendor dependent. But it is not reasonible
to pretend to be independent to the DBMS vendor.

It would be like to pretend to be language vendor independent.

> The
>most important customer demand today is database independence.

That is an astonishing statement.

> 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.

Agreed. It is a lot of work to build a very poor interface.

Regards

Relevant Pages

  • Re: Database design pattern qestion
    ... Is the binary string a fixed length? ... For database design, start by asking what is it that you are modeling? ... What attributes does a client have? ... you will prepare the model by normalizing it. ...
    (comp.databases)
  • Re: Can it be done?
    ... The place to start with such a question is the database design. ... Presumably you have a Client table and a related AdvertisingInfo table. ... Does AdvertisingInfo or an Option apply to just one client, or could it apply to several clients? ...
    (microsoft.public.access.forms)
  • Re: Calculated Field in a Table
    ... Currently, the database design is ... and I wanted to provide my client with a quick fix that ... and included forms for data entry:) ...
    (microsoft.public.access.tablesdbdesign)