In my own experince, i was writting an ASP.NET application which uses SQL Server 2005 & Visual Studio 2005. Later, i discovered that i needed to update my database structure because i wanted to add some extra functionalities, so i need to add and delete a few database (db) tables, renaming some of my existing db's tables. Some changes had significant impact on my application while some had not. Therefore i needed to take this into consideration as well. After i had made the changes, I found that my data access logic layer seem to be useless because data access code actually maps back to the database structure, therefore it was no suprise. Luckly, my web application is 3-Tiers design which allows me to replace it with a new code generated data access layer (DAL). This is the most simplest part. Now it comes for modifying the business logic layer (BLL), because this layer actually calls your DAL, therefore changes need to be performed , you can't throw away your BLL and replaced it, you just need to spend your time modifying the calling object to your database.
Notes, renaming your tables and column names or deleting tables have the most
significant impact on yur BLL, on the other hand, adding new columns or tables
are not. (it depends how smart your ORM generator) .
After i'd made the changes and to make sure my BLL talks well with my DAL, then I need to make sure my UI calls my BLL well. Do i need to make changes to my UI code to make sure it talks well with my BLL? The answer is yes and no. if you expose your BLL as services interface then no changes nessary to your UI code, The answer is no and assuming that you want to preserve your previous functionality. If you do not have interface class, method overloading and constructor overloading presented in your BLL design, then the answer is yes and most problably that you need to make some changes to reflex your BLL :)
Finally, what if i am using this VS table adapter and dataset to bind data? The best answer is you have to check and make sure they are actually maps to your database's tables correctly, otherwise you need to regenerate or redesign your databinding again. However, this modification is not tredius and time consuming as you might think.
The question is how to eliminate these problems of code changes when database structure is being modified? In my personal opinion, i don't think we have the economically way to eliminate these problems. What we really care is try to make your UI design as simple as possible by abstracting the object calling either business layer or database layer. By this means, you are pretty save when disaster comes, you could easily solve it because you just made it simple.
No comments:
Post a Comment