[Arp] The right way to use VO/TO's

[Chris Velevitch]

On 3/18/06, Zoltan Csibi <zoltan at thesilentgroup.com> wrote:
> Let us call it for simplicity a "three-tier client/server architecture"
> where the client implements the presentation logic, the business logic is
> implemented on an application server and the data resides on database
> server...this is the case we started to discuss

If you're trying to say all business logic must be in the application
server, then that is my point of contention. In some cases it's not
feasible. In other cases, it's not practical. In addition, there are
some cases where the business logic must be or should repeated in 2 or
more, if not all tiers.

The database is the classic case. You don't just store data. You
include typing rules for fields, foreign key constraints, uniqueness
constraints, null value constraints, relationship constraints,
auto-incrementing integer columns, transactions, etc. The database
will reject any attempt to violate any of these rules.

Typing rules most likely to be applied across all tiers. Why wait
until the database rejects database because it's the wrong type.

Then there's the hidden business logic implied by the design of the
way data is entered: check boxes, radio buttons, combo boxes and
(multi-)selection lists.


Chris
--
Chris Velevitch
Manager - Sydney Flash Platform Developers Group
www.flashdev.org.au