|
|
Posted by A. Timurhan Cevik on 10/09/84 11:33
Like any database driven program you should start by defining your
schema ?
Thats not the way to oop. Never do that, if you plan to program oop.
Sure, you should do it, but if you are procedural programming or you
lack skills to construct an oo program.
I dont think I made that strong enough, do not start by defining the
schema if you are into oop. Simply do not.
In oop, business layer is business layer. Not the database layer. So,
you should keep your business objects out of persistence code. Doing
not so, makes your code tough to be reusable, encapsulated and such.
Persistence should be handled AFTER the business objects are
constructed and proven to be running good.
It would hurt too to Unit test these classes.
Sure, there are objects that handle persistence. Sure, you can make an
object for each table on your database (Active Record pattern or smth.)
but, that application should not be a big application, if it is, then
you will be making a lot of maintanence, bug fix during the project
lifetime, trying to complete it and trying to change it to meet the
requirements afterwards.
Software change. You should not make it unchangable. So, you should
design it such that changes in layers should affect other layers as
minimum as possible. Highly couling the database schema and the class
structure, you will be violating that.
Navigation:
[Reply to this message]
|