OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Implement data rules in application code?

I have a very simple view on what the approach to this should be.

1. Keep all business rules in a separate layer outside of application code - whatever you choose that layer to be.
2. Make exceptions to Rule 1 for specific edge cases that are
a) well documented and justified
b) ring-fenced in the code

The discipline of an enforced separation of validation/business rules layer is necessary because it prevents undesirable cohesion between such functionality and other components. Otherwise chances are you will end up in the scenario posited below (it is an excerpt from  a Linkedin post by Dave Ziffler).

 I've been designing and coding applications for 40 years and I can tell you the greatest cost to companies that develop custom software: it is the ongoing maintenance and operational cost of poorly written applications. I see tons of coders coming out of schools with all sorts of computer language skills and UI subsystem knowledge (jQuery, Angular, you name it), but very few of them have the sorts of skills required to build code that is both efficient and comprehensible to others. To create quality code, a programmer needs fundamental organizational skills that predated the computer era and will no doubt postdate it as well: what are the components of the problem, how do you group the components appropriately, how do you model the problem in an elegant and extensible way, etc. Programmers lacking either these fundamental thinking skills or the discipline to use them, which is most programmers, write code that is a labyrinth of unnecessary complexity, redundancy, and confusion, and which is lacking in fundamental integrity (transactional integrity, data integrity, idempotence, etc.). By using enough trial-and-error you can get such code to pass its unit tests on day one, which is enough to make most managers happy. But all of these failures produce huge ongoing operational and maintenance costs that have plagued almost every organization I've ever worked for. I contend that most of the world's software systems would collapse within a week if they were not constantly attended to by an army of tens of thousands of IT staffers, constantly manually compensating for these systems' shortcomings.</quote>

On Wed, Apr 12, 2017 at 3:43 AM, Rick Jelliffe <rjelliffe@allette.com.au> wrote:
I have often felt concern for how difficult filling out forms must be for Dr Who. Which address should he give, if he can be multiple places at the same external time? If he cannot reveal his name, I guess he gets his wife to fill in that part of the form? How would he handle choosing his age from a pull down list? Better to run around old quarries rather than fill in a form.

I expect most of us know people with similar problems: an Indonesian mate has only one name "What is your first name?" "Munali" What is your last name?" "Munali" "So Munali Munali?" "No just Munali".  Transgender people must be quite patient. Are validations against men having husbands or women having wives being disabled as we sit here?


On 12 Apr 2017 17:27, "Michael Kay" <mike@saxonica.com> wrote:
> For example, that your travel-agency application does not handle red-haired people.

And in practice, many integrity constraints are actually guards to prevent "edge cases" reaching the application when the application can't handle them.

Typical example: every bank branch must have a postal address. Meaning: sorry, this application can't handle the travelling bank-in-a-bus that we introduced to serve remote rural communities. You're just going to have to give the bus a dummy address, or things won't work.

Michael Kay

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS