Ideally your data abstraction classes should be isolating you from your database implementation. Meaning, you should not have to change any code that uses them if you change the database structure, assuming of course your change isnt so major as to require a rethinking/recoding of said data abstraction classes. Of course this is idealistic and in reality it may not be this black and white.
Personally the way I avoid database structural changes rippling throughout my code, is by using a set of Object Relational Mapping classes. Usually comprised of an Entity class and matching Data Access class, although sometimes they are combined into a single class. I then make sure from that point on all my other code only uses the Entity classes interface. As long as the metaphor my entity is based on is solid, then I find any underlying database changes have minimal effect. More often than not, additions are the only noticable changes.
-stvnIn reply to Re: Database field names in code
by stvn
in thread Database field names in code
by disciple
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |