Hi to All, I'm new of this discussion group.
In the last weeks Matthew and me had a little duscussion about to give to the developer the possibility to add Business Logic to the DataObject ( especially DataObjectImpl object ) using a well defined pattern. The Idea consists of build a mechanism to intercect the state changes of the DataObject, that is, before and after any change of its internal data member and before and after CRUD operations. At the moment this kind of implementation is limited (it's a prototype) to the SDO_DAS_Relational branch of the project but it could be easily extended to the XML, involving the webservices use in the next future. The advantages of this kind of implementations could be: 1) Write Business Classes (classes implementing particular BO interfaces) that can be attached dynamically to a particular Type of DataObject. That is, every time a DataObject's property is to be changed a Business Class Method will be invoked to apply the correct rules, returning the status of the operation to choose to going on with the property change. 2) Write Business Object that can be attached to a particular istance of DataObject 3) Write Business Class containig validation rules to apply before and after data persistence operations. 4) Add to an DataObject Class properties that don't have DB fields correspondance. Using them as volatile fields than can be use for different pourpose even if they can be validate by Business Rules as well as all other members. 5) Centralization of all the Business Validation Rules and Operations with all the advantages for interchanges of "intelligences" or only for mantenaince semplicity. 6) Association between Business Class and DataObject Type ( seen as Business Entity ) should be defined also in configuration files ( XML definition for istance ) permitting to switch from an hard-coded behaviour of the application to a meta-data defined one. 7) A great abstraction level and a defined separation from data logic and presentation could encourage developers to apply the patterns that more fit their needs ( MVC, Pipelines etc etc) 8) This additional layer will be written entirely in PHP. Some aspects will be also well considered in deep accourding with the possibilities offered by the SDO_DAS_Relational framework. More work and considerations will have to be done to build a all needs inclusive solution (accourding with human possibility :-)). This post would be a starting point to discuss this issue, get suggestions or particular needs, verify the interest of this groups about it, and to give information to you to get a better idea of the solution. Thank you for your attention, Best Regards, Antonello --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
