|
|
Posted by amygdala on 04/13/07 17:26
"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?
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!
Navigation:
[Reply to this message]
|