Posted by Jerry Stuckle on 04/14/07 02:36

amygdala wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> schreef in bericht
> news:mpmdnf_eobam7ILbnZ2dnUVZ_riknZ2d@comcast.com...
>> amygdala wrote:
>
> <snip>
>
>> And as you add more types and subtypes, this gets longer and longer. And
>> slower and slower. And harder to maintain and more subject to errors.
>
> <snip>
>
>> And you'll have to add more custom validators plus hooks for them.
>
> <snip>
>
>> And what about cases where you need non-consecutive numbers? Such as
>> those from the set (1, 2, 3, 5, 8, 13, 21...)? Another custom
>> validator...
>
> <snip>
>
>> The generic will be much larger, much slower and much harder to maintain.
>
> <snip>
>
>> Yes, it's easy to get one idea in your mind as the best way and stick to
>> it too long. You need to be flexible. Even after 40 years of programming
>> I sometimes have to change my approach because someone shows me a better
>> way.
>
> <snip>
>
>> I create db objects all the time. But they have get and set functions for
>> each field (at least the appropriate ones). They are quite handy for a
>> number of purposes - the biggest one being abstracting the database
>> access. But then that's their major purpose.
>>
>> For instance - one I'm on right now. I have a site coded in VBScript
>> using Access. I want to change it to PHP and MySQL. However, for various
>> reasons this needs to be done in stages. The Access database has over 30
>> tables, ranging from 2 columns to over 40 columns per table.
>>
>> We're (others are involved - it's a big site) creating DB objects to
>> interface the Access tables. These will handle the actual SQL calls and
>> isolates the program from the database being used (or even flat files, if
>> necessary).
>>
>> Next we'll creating business objects - these objects translate between the
>> program and the database objects, and convert what's in the tables to a
>> format the rest of the program needs. This isolates the rest of the code
>> from the database table design (i.e. if we need to change one or more
>> tables, this and the db objects are all that will need changing).
>>
>> We'll then convert sections of the site at a time. Once we get a section
>> converted, we'll bring it online.
>>
>> When we're done and can change from the Access database to MySQL, we'll
>> change the Database layer and move the data. If at the same time we need
>> to change some of the table design, this will be handled between the
>> database and business object layers. But any changes will be isolated to
>> those layers.
>>
>> Note the business object layer isn't always needed. But due to the
>> complexity of the site and how many tables are interrelated, we decided it
>> would be better to use them here.
>>
>> These are the benefits of database objects (and OO in general).
>> But I would hate to use your fieldspec idea in this case. It would make
>> things much harder to troubleshoot, and we'd end up with a lot of
>> specialized validators. The result would rapidly become unmanageable.
>>
>> So we're putting in the set and get functions for several hundred table
>> columns. Additionally, we're doing a similar number on the business
>> object end. And depending on the data, it may be validated in either
>> level.
>>
>
> Some darned good points Jerry. Especially the getting too large and slow
> parts are starting to convince me
>
> Good point about the flexibility too! I try my best to keep up a flexible
> attitude. The thing is though that I often get caught up in trying to
> generalize things too much and/or mixing up in what 'layer' certain routines
> should take place.
>
> For instance, as you put in your example: Where would validating in the
> bussiness objects stop and validating in DB objects start, or vice versa.
> Are there some ground rules or methodologies for determining this in early
> stages of coding a project? Do you know of some pointers; some good clear
> articles perhaps?
>

Generally the business object is at least (if not more) restrictive than
the database object, so the validation would be done in the business
object. I don't normally validate in the database object if it's not
being accessed by the program itself.

> Just out of curiousity though. I assume that you _do_ have some sort of
> generic validator routines for repeating column / field validation right?
> For instance a generic validateEmail() function which you call for the
> specific task when doing a setEmail. You're not reinventing the wheel in
> each and every getter methods right?
>
> Thanks again!
>
>

Not necessarily functions - just some spare code running around. I
either copy and paste into a function or create a validator function
with it, depending on my needs.

I generally don't create a separate function just to validate one
attribute. I just put the code directly in the setxxx function.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]