Re: Application logic and Business logic
From: topmind (topmind_at_technologist.com)
Date: 02/28/05
- Next message: topmind: "Re: Disadvantages of Inheritance, Polymorphism and Encapsulation"
- Previous message: topmind: "Re: Application logic and Business logic"
- In reply to: Thomas Gagne: "Re: Application logic and Business logic"
- Next in thread: Thomas Gagne: "Re: Application logic and Business logic"
- Reply: Thomas Gagne: "Re: Application logic and Business logic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 27 Feb 2005 22:23:04 -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. *)
The problem is not because it wasn't wrapped or separated, but because
HTML and HTTP put *restraints* on UI flow that client/server systems
didn't face. It is like writing output for a color printer, and then 5
years later you get a black-and-white one instead. Either you live with
less options for 5 years, or you live with all the rich options your
current system provides and worry about what-ifs later. And, this is
assuming you could have predicted the loss of features. This is not
merely a change of implementation, but a change in fundimental UI
philosophy.
Besides, if it was a matter of plug-and-play swapping, then why not
just write the client/server API's to do HTML instead? Many c/s systems
talked thru API's rather than raw system calls, so just re-implement
them for web. Why not? Because HTML is too limited to handle c/s API's.
(* 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., and for the
business layer to have hardwired itself to a specific table layout is
nearly
as restrictive as mixing business and UI logic. *)
I will agree that for THAT particular change, grouping all the SQL
together would make it simpler. However, when dealing with
task-specific changes it makes some things harder because you have to
change BOTH the interface and the implementation. Thus, you have 2
places to change where you would only have one if there was no
separation. Separation creats a mini-buerocracy.
I've had this debate a jillion times. Indirection is NOT free. Spend it
wisely, not out of mantra.
(* Better to treat the database as a huge object... *)
Yeah, OO zealots want to tree *everything* as a "huge object". No news
there.
-T-
oop.ismad.com
- Next message: topmind: "Re: Disadvantages of Inheritance, Polymorphism and Encapsulation"
- Previous message: topmind: "Re: Application logic and Business logic"
- In reply to: Thomas Gagne: "Re: Application logic and Business logic"
- Next in thread: Thomas Gagne: "Re: Application logic and Business logic"
- Reply: Thomas Gagne: "Re: Application logic and Business logic"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|