Re: Application logic and Business logic

From: Thomas Gagne (tgagne_at_wide-open-west.com)
Date: 02/28/05 

Date: Sun, 27 Feb 2005 21:40:41 -0500

topmind wrote:
> (* That's an interesting assertion. What evidence do you have to
> support it? *)
>
> "Decision math". The chances of switching to a different GUI or DB
> vendor is relatively small compared to the cost of the extra separation
> layers in terms of coding and maintenence. Add in the "future
> discounting" from finance principles, and the the total weighs in favor
> of not doing it.

I might regret this...

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.

Later in the 90s and early 00s XML was revealed to the masses. How great it
was for those of us with separated logic to easily and quickly front-end our
systems with XML xactions and eventually web services.

All these great new markets, functionality, and interoperability with nary a
modification to the expensive code.

More simply, imagine you're a bank (or a firetruck) accustomed to doing
transactions for tellers on dumb terminals. Over the course of a few years
you need to handle PCs, windowing interfaces, new ATM networks, POS networks,
and your own private ATM networks.

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

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.

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.

Relevant Pages

  • Re: "Business Objects" and the DAL
    ... layer talks to the layer next to it. ... business entity returned that up to the UI for binding to a grid. ... If a database table column names ... Each could be considered a "pattern", ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Returning typed DataRow from WebMethod
    ... So I've created a typed dataset from my database (a table called ... business layer doing all the business logic, ... these objects from my business tier to my presentation tier. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Newbie object design questions
    ... generate typed datasets from stored procedures, ... When you come along to change things in the database, ... > database in the same way that the business thinks of them. ... > Mediating between these two points of view is what a business layer is ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Am i thinking correctly?? business objects inserting to database
    ... We are building the new application using a 3 tier ... What I generally do is create a class for each business object. ... classes themselves know nothing of the database. ... Next I create Data Access layer that knows how to take a Value object ...
    (microsoft.public.dotnet.general)
  • Re: Ms Access 2003
    ... employees to build a database application or use their department budget to ... I find that some businesses will pay, ... a small business which employs five consultants. ... when I was a corporate Access developer for a little more than a year. ...
    (comp.databases.ms-access)