note 83593 modified in language.oop5.patterns by felipe

Db layer design algorithm: "Separation of database layer by database functionality" First we draw this line: Application ------------- DB Here comes the new thing: The db layer we separate it into two areas like this: Db layer | select | insert, update delete | in the left side we have the select part. The difference between the left and the right sides is that select side has no connection with the db structure - you can take data querying all table, while the right side is table oriented. Select side: Here all queries are in one file called "getters". Like getterUsers. Inside it will be the body of the query but the fields that are to be selected will be build dynamically. When calling this "getter" you will provide an array of fields to be selected or no fields, situation when it will take all fields. To keep those db field names as low as possible in this architecture - so the above code dont need to know about the name of the fields in db, you will make just above this "getter", a "filter" file. This filter will have a switch with a key and inside will call the getter with fields from db. Ex: <?php switch(key) case 'Label': $fields = array("label", "firstName"); $obj->getUser($fields) break; ?> Above this filter you will have a "caller" that will call the "filter" with the key: Ex: <?php function callerUserLabel() { ->filterUserLabel('Label'); } ?> So in the higher code you just make ->callerUserLabel(); and this will return all what you need. If you want this query to get out of the db and another field called "email", you just create another case in the switch and a "caller" to call that case. Dynamic and extensible. ---------------- Now on the insert update side. Here we only think in db tables. First we do some "checkers" for all fields in db. checkerTableName.php This will contain an array with all the fields and the checks that must be done on that field and perform the checks only on the provided fields. Then we do the "updaters". Those are build dinamically like the "getters" - if fields provided, only those updated. If all fields provided, can be used as an "inserter". When performing an insert, all checks on that table will be done. When performing an update on only one field - like updating a label, only that label will be checked to be in conformity with requirements like a length, special chars inside. Dependency checks are made here also. When having in one application action a multiple insert or update (when inserting an operator also add a webUser lets say) you do above those "inserter" and "updater" files a small "manager" that will do: ->checkOperatorFields(); ->checkWebUserFields(); ->insertOperator(); ->insertWebUser(); If no error is thrown, all things will go nice and quiet. Now also the "getters" will have their fields checked when needed using those checkers. I am talking about the values that are given as parameters not about the ones that are returned from db. If you are working with domain objects or business logic objects (whatever you call them) above the db layer you will have to make below that line we first draw a "business logic asambler" object that will make from your data what you want. If this dont exist, at least an intermediary layer that will map the names from db with the ones used in application must be done in both directions - from application to db and from db to application. ------------------------------------- Advantages of this architecture: - Usefull in complex application especheally where the selects are made ussually from many tables so you dont have to load lots and lots of files and to get lost in the logic for one simple select. - NO DUPLICATE CODE - Simple and intuitive. - Flexible and expendable. ----------- "A place where this idea is exposed completely or to debate on it:" http://www.kurzweilai.net/mindx/show_thread.php?rootID=122913 --was-- <?php Db layer design algorithm: "Separation of database layer by database functionality" First we draw this line: Application ------------- DB Here comes the new thing: The db layer we separate it into two areas like this: Db layer | select | insert, update delete | in the left side we have the select part. The difference between the left and the right sides is that select side has no connection with the db structure - you can take data querying all table, while the right side is table oriented. Select side: Here all queries are in one file called "getters". Like getterUsers. Inside it will be the body of the query but the fields that are to be selected will be build dynamically. When calling this "getter" you will provide an array of fields to be selected or no fields, situation when it will take all fields. To keep those db field names as low as possible in this architecture - so the above code dont need to know about the name of the fields in db, you will make just above this "getter", a "filter" file. This filter will have a switch with a key and inside will call the getter with fields from db. Ex: switch(key) case 'Label': $fields = array("label", "firstName"); $obj->getUser($fields) break; Above this filter you will have a "caller" that will call the "filter" with the key: Ex: function callerUserLabel() { ->filterUserLabel('Label'); } So in the higher code you just make ->callerUserLabel(); and this will return all what you need. If you want this query to get out of the db and another field called "email", you just create another case in the switch and a "caller" to call that case. Dynamic and extensible. ---------------- Now on the insert update side. Here we only think in db tables. First we do some "checkers" for all fields in db. checkerTableName.php This will contain an array with all the fields and the checks that must be done on that field and perform the checks only on the provided fields. Then we do the "updaters". Those are build dinamically like the "getters" - if fields provided, only those updated. If all fields provided, can be used as an "inserter". When performing an insert, all checks on that table will be done. When performing an update on only one field - like updating a label, only that label will be checked to be in conformity with requirements like a length, special chars inside. Dependency checks are made here also. When having in one application action a multiple insert or update (when inserting an operator also add a webUser lets say) you do above those "inserter" and "updater" files a small "manager" that will do: ->checkOperatorFields(); ->checkWebUserFields(); ->insertOperator(); ->insertWebUser(); If no error is thrown, all things will go nice and quiet. Now also the "getters" will have their fields checked when needed using those checkers. I am talking about the values that are given as parameters not about the ones that are returned from db. If you are working with domain objects or business logic objects (whatever you call them) above the db layer you will have to make below that line we first draw a "business logic asambler" object that will make from your data what you want. If this dont exist, at least an intermediary layer that will map the names from db with the ones used in application must be done in both directions - from application to db and from db to application. ------------------------------------- Advantages of this architecture: - Usefull in complex application especheally where the selects are made ussually from many tables so you dont have to load lots and lots of files and to get lost in the logic for one simple select. - NO DUPLICATE CODE - Simple and intuitive. - Flexible and expendable. ----------- "A place where this idea is exposed completely or to debate on it:" ?> http://www.kurzweilai.net/mindx/show_thread.php?rootID=122913 http://php.net/manual/en/language.oop5.patterns.php