Re: Multiple specification of constraints

"Mike Sherrill" <MSherrillnonono_at_compuserve.com> wrote in message news:bp4s30td62buv8vo101rthuhm6gja6vl8v_at_4ax.com...
> On Wed, 25 Feb 2004 12:39:18 -0600, "Dawn M. Wolthuis"
> <dwolt_at_tincat-group.com> wrote:
>
> [snip]
> >My point is that with the way that software is written today, quite often
> >data constraints are coded in multiple places, even multiple languages.
>
> That's certainly true. But the problem is not necessarily in having
> multiple expressions of a constraint. The problem is in having
> multiple uncontrolled expressions of a constraint.
>
> >I'm suggesting something rather radical --
> >decouple the constraint specification and validation logic from the
> >database.
>
> Why? It's not crystal clear from what you posted.

I'll start with a couple of definitions of the word "service" as requested in a previous response in this topic.

From Dale Asberry on the jini-users list: "A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services."

and from the W3C:

"...a service is a software agent that performs some well-defined operation (i.e., "provides a service") and can be invoked outside of the context of a larger application."

What I mean by decoupling is that the constraint & validation "services" be able to be used independent from the CRUD services. The CRUD services would then be clients of the constraint services, as would the UI.

I think of everything as functions and everything as objects. Instead of the term "relational operators" they beome functions on functions, for example. The client needs to know how to tell the service to start, pass it parameters, and receive the output. The client does not need to know what run-time environment the service will run in, nor anything else about the implementation of the service.

If there is a validation service for a specific type that is available (anywhere on the internet, for example) to your UI or front-end service and to your CRUD services, then your application could be a client of this same service twice. A possibility would be that there be a States validation service and a country validation service so your application need not have a table of states and another of countries itself. The service could return a boolean for whether the entered data is a state (counrty) and the name of the state based on the abbrev entered. My software application could use the same service as yours, which we could both license from a service provider.

Just a thought -- as with every possible solution, there are pros and cons. But this approach eliminates specifying constraints in your database using one set of tools and then again in your UI using another set of specs (and logic and run-time environment). Given that most types of data handled by one company are also handled in others, and that a significant part of writing software has to do with the validation information related to various types, there could conceivably be more reuse within a company and across companies. Given that an order is prepared by one company and then processed by another, they could both use the same services for validating the information so there is no guessing of what the validation functions/services will do at the other company. If you track one piece of data today from entry through to archival, how many different programmers/dbas using how many different toolsets are writing sortof-similar-and-should-be-the-same constraint logic? Too many, methinks.

 --dawn Received on Fri Mar 05 2004 - 16:44:07 CET