Re: OOP/OOD Philosophy

Finally... We get to the crux of the matter... what does it mean to isolate
one from another?

You appear to assume that, in order to isolate the database from the gui,
that you have to abandon data bound controls.

I would challenge that assumption by asking you to look at the definitions a
little different.

In general, let's say that layers are bound to each other across interfaces.
In other words, the GUI layer uses a specific interface of the business
objects layer. Therefore, when data is transferred across these boundaries,
the specification of that data is included in the specification of the
interface.

You appear to be happy with using automated components that will actively
adapt to changes in the contents of the data view. I agree with this
notion. As much as possible, and where data transactional efficiency is not
a problem (as in the case of a CRUD interface), this is a good idea.

I'd like to point out that, in this case, the specification of data
interaction did not change even when the number of columns did, because the
interface will handle ANY and ALL fields, not just specific fields.

The problem for maintenance comes when you need to make exceptions to the
basic rules of "user knows best" to do things like restrict a single column
to a preset list of values, or to validate that a particular field, present
in the data structure, should not appear in a grid along with the rest of
the columns.

This is where you need to place logic against the data structure that
doesn't just apply to ALL fields. This is where headaches start.

I am hoping to encourage caution about this kind of binding. If changing
the name of a column in a database causes your code to break, because your
code was looking for that column name to exclude from a grid, and the column
is 500 bytes wide, and now the grid scrolls wildly, and the user won't be
happy, then it is fair to say that you have not isolated the db change from
the front end. This is because the name of the database column appears in
the front end code, potentially in many places, in order to perform this
very specific exclusion.

On the other hand, if your data layer always _maps_ a database column name
to a gui-friendly name that allows the db field name to change
independently, then you can continue to use a data-bound control without
fear that these exceptions can cause additional cost.

There is a little known feature of the Microsoft .Net framework that does
this for data sets. If you use the Visual Studio wizard to build a data
adapter, and then take a look at the code that was generated, you'll see the
use of the DataTableMapping object that allows for this level of
indirection, while still allowing you to use the data bound controls for
front-end mechanisms. I do not know if you use Microsoft .Net for writing
code, and I'm not trying to convince you to do so. However, it may be
interesting to take a look at the following topic in the documentation to
see how it works:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbcontablemappingindataadapters.asp

This keeps with the notion of independence between the database and the
front end while still allowing the use of automated tools that interpret the
data structure in a consistent manner for the creation of automated GUIs.

Also, another little known features of the .Net platform is that you can
create your middleware objects, and then bind the data controls directly to
them, giving you the ability to code your business rules directly to your
own objects, and then handle persistence downstream independently. These
are patterns that not often used, because their structural benefits are not
well understood by the majority of developers. However, they have the real
ability to make maintenance more efficient.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: Beginning C# Q
    ... starting out with a network app0lication, you have an awful lot to swallow. ... Designing your database is therefore, not quite the first step, particularly ... Groups table, which defines which Groups users belong to, and a Permissions ... That is why an Interface is called an Interface. ...
    (microsoft.public.dotnet.framework)
  • Re: Transaction Oriented Architecture (TOA)
    ... If one builds the application around the database view, ... The problem solution should not have to know about mechanisms like SQL query construction, optimizations like anticipatory caches, or encoding/decoding of dataset formats. ... Note that the CRUD/USER environments already provide exactly that encapsulation by providing a Data Layer that is isolated from the rest of the application through an interface. ... TOA/TOP proposes the database and its application domain stored procedures are the only persistence mechanism necessary, and that the benefits of a focused, single, data-permeable gateway between application and database far exceed the benefits of O/R mappings--regardless of abstraction--and that its lightweight appearance shouldn't be dismissed as missing heavyweight kick. ...
    (comp.object)
  • Re: Transaction Oriented Architecture (TOA)
    ... I don't think the issue is ignoring the database; it is recognizing that the database is a different subject matter applying different business rules than the problem solution. ... There is nothing to prevent abstracting the database subject matter in a classic OO manner with objects like Schema, Table, Tuple, and Query. ... I'm of the opinion that the more obvious the database (or at least its interface) is the more easily maintainable an application becomes. ... I've nothing against creating frameworks and patterns to facilitate those programming activities, but prefer the concept of a problem domain transaction to language-specific expressions mapping 1:1 with anything physically present in the database. ...
    (comp.object)
  • Re: OOP style
    ... Component classes have all their main logic in a Custom base class ... database access unit if they didn't already start with a full DB layer; ... My latest application started with an extensively designed object model ... Typing in the implementation of the database interface is ...
    (comp.lang.pascal.delphi.misc)
  • Re: Virtex 4 FIFO16 blocks - Corruption ?
    ... I am not asking forgiveness, but asking for some help in how to deal with these issues. ... One minor difference for me may be that when I find unusual behavior and have it isolated to a functional portion of the design, I may check the knowledge database for any information relating to my problem area before spending a few more days to further isolate the cause. ... A simple statement in the user's guide saying that the FIFO16 is an async FIFO and has these particular limitations when used in an application where both clocks are the same would have been sufficient to avoid a heck of a lot of troubleshooting time, and would have put the onus on me the designer. ...
    (comp.arch.fpga)