Re: OOP/OOD Philosophy

> if we are developing a system that must survive through years of
> changing requirements, then coupling the GUI to the Schema is suicide;
> and the time you might save in so doing is a false economy.

Why would it be suicide to have a coupling between the GUI and database
schema? As pointed out before, a simple column adding would cause you a
lot of extra coding using a decoupled approach. With the coupled
approach, the new column could appear automatically in the GUI after it
is added to the database table. It is easy to prove that the coupled
approach makes maintainance much easier.

How would it be easier to maintain "system that must survive through
years of changing requirements", by doing simple things harder?

Fredrik Bertilsson
http://butler.sourceforge.net

.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... > GUI and database schema?" ... Because that is the definition of coupling: When it's suicide. ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... I asked you " Why would it be suicide to have a coupling between the ... between the GUI and database schema? ...
    (comp.object)
  • Re: Why not many2one with pk array type
    ... > schema is easier when the schema is tree-like....where ... Relational design is inescapably subjective. ... GUI and relational schema for thousands of programmer years. ... To automate more than they have already is impossible. ...
    (comp.databases.theory)
  • Re: OOP/OOD Philosophy
    ... >> I am not disagreeing with the decoupling of the>GUI layout from the database schema ...
    (comp.object)
  • Re: Cannot transfer Schema Master
    ... role to another DC through this GUI, but I got the following error when I ... the current Operations Master could not be performed." ... warning that DC1.child1 could not resolve the name for role Schema Owner. ...
    (microsoft.public.windows.server.active_directory)
Loading