|
Logical Views v. Physical Views when dealing with Table Rows |
|
|
|
|
Written by Frotz
|
|
Friday, 15 December 2006 |
I think I'd classify this as solid API protection and/or information hiding of the normalized table structure. Using a logical view of all of the associated tables underneath a class may be worth it if you have normalized tables that are conditional, and/or oddly, yet appropriately, tied together.
Logical Views v. Physical Views in a Table Row implementationI found that the strict, almost blind, adherence to requiring classes that provide a strict physical view of the data was both unsatisfactory and problematic as it required the Physical Table Row caller to know and adhere to the various business rules.
Solution
I found that by implementing individual Physical Table Row classes and then moving the controlling class to a Logical Table Row implementation that I was able to hide the arcane business rules to a large extent and reduce the detailed knowledge required by the API callers.
This unexpected shift in implementation occurred because I did my unit tests near the same time that I was completing my implementation. This forced me to try and use my classes and see what level of detail was required above my Physical Table Row views. That, in turn, led me to the Logical Table Row perspective. Something that I'm fairly happy with, but will now have to justify in my particular environment because we're culturally attuned to the purely Physical Table Row model. |
|
Last Updated ( Friday, 15 December 2006 )
|
