Re: Separating business logic from data store logic

I realize this topic might be a little stale, but I just came across it & wanted to mention a couple of things. There are a few projects that are tackling these business logic / datastore logic issues. I think that DB_Schema project that Lukas proposes sounds very vast -- and potentially very powerful.

Phase I) Unify all configurations in one XML file. This XML file focuses on structuring the data and defining relations among

each other. This is what I am trying to achieve with DB_Schema. The result be a basic framework which will assist in transforming the structure out of any datasource into a structure for another datasource.

I'm leading development on Propel (propel.tigris.org) an object persistence layer for PHP5 based on Apache Torque. In some ways this has some overlap with current MDB Schema -- in that datamodel is defined in XML. From that XML definition PHP base classes are generated to work with the object model. E.g. to provide the functions like $author->getBooks(). This code generation model works quite well, since empty subclasses are also generated -- and it is in these empty subclasses that all of the app's business logic goes. It would be neat to see a generic Schema tool that could drive the Propel datamodel definitions. Even if Propel didn't use/depend directly on Schema, a simple XSLT should enable generation of Propel XML from DB_Schema XML. In short, DB_Schema sounds like a very cool project.

Phase II) From this we can build to further integrate each of the various classes. The idea will be that the configuration files become more and more similar.

That functionality is not duplicated needlessly.

Propel obviously has rather limited goals -- but there are other projects out there aim more toward satisfying Phase II. For example, the Combine project (combine.tigris.org) aims to provides a Turbine-like system in PHP(5?), where datamodel and forms/actions are all generated based on XML schema. Similarly, Binarycloud (binarycloud.tigris.org) uses a single entity definition (XML) to driving creation of business objects, forms, validation, etc. It would be awesome if PEAR could provide a set of useful building blocks that would pull these applications together -- or give them a common vocabulary, at least. I'm very eager to see what will happen with DB_Schema. (And what will happen w/ PEAR given all recent discussions of things like PEAR2....) Cheers, Hans