Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1tt55$k12$1_at_news.netins.net...
> I am in full agreement that we don't want to validate twice if we don't
have
> to. But if we are tossing up a question to a user, or deciding whether to
> use a radio button or combo boxes or a text field entry or a calendar for
> date entry then where are we getting the validation from? Do we read the
> metadata from the database in order to put the proper information and
format
> to the UI? If so, then won't we validate again when we do CRUD routines?

Sure. The database serves many masters. Why should it trust anyone that's talking to it (most likely quite a few different programs) to have done the validation?

Things that need to stay in sync must be generated from a common source which describes the essence of what must be synchronized. A true RDBMS is a great source. As another sort of approach, check into Model Driven Architecture (MDA), though using the UML's OCL as a basis is a rather dicey proposition at best.

> If we are reading the typing and constraint specs from the database prior
to
> doing any CRUD routines (e.g. in order to give the user an interface to
add
> or lookup data) then the engine we are using to interpret those specs is
> different than the database engine, right?

Not necessarily - languages can be interepreted on many platforms and in many technologies. You're talking about language commonality, not singleton components. But the DBMS is the source of what is to be interpreted (e.g. the constraints).

> I would be thrilled to find out that I'm missing something here, but it
> seems to me that it is absolutely bottom-line required to have a large
> portion of the constraint information present when presenting an interface
> to the user (or to the web service for that matter, although I don't mean
to
> muddy the waters any further with that point). That means that the
> specifications of the constraints, the interpretation of the constraints,
> and the run-time environment in which to test out the constraints should
be
> part of the UI environment,

Why the specification of the constraints? Interpretation, yes; runtime, maybe, although that needn't be the same UI either. But the specification can be anywhere - is your source code always in the same directory as your executable code, or even on the same machine?

> while today it looks to me like both .NET and
> J2EE developers REWRITE IT so there are (at least) two sets of data typing
> and other constraint information.

This is a common and incorrect approach.

> Furthermore, if we are certain the data can only come into the database
via
> a particular (set of ) service(s)

In my experience, if the data is useful it will be demanded on many fronts. Furthermore, I've mostly worked in companies with technological heterogeneity, so couldn't count on even what language would be accessing the data. Furthermore, protocols and standards (like Web Services) come and go - do you want that to be the basis of everything?

> and we know that service necessarily
> operates the constraint logic in this or a prior step, then there is no
need
> (except that inner sanctum thing for extraordinary applications) for
> reapplying the constraint logic to the data, right?

An RDBMS could express much more than web services.

> That would be fine if the database specifications, logic, and run-time
> environment were present in the UI. But as far as I can see, it typcally
is
> not. Cheers! --dawn

Even without the DB runtime, it's not rocket science to generate UIs (e.g. the HTML drop-downs and such) for a given hierarchy superimposed over your relational database (e.g. a view of the data starting with relation X and extending to relations Y and Z). But it would definitely be much, much better to do so.

• erk