I don't agree that UMLs are a waste of time, but I would appreciate a little guidance as to where to start with this one. It's pretty large and so it's hard to make sense of everything. So, I think the first thing you could do is break it up into three separate UMLs one for the view, model, and controller. That way we could consume them individually and come back to the entire UML with greater understanding.
I've considered that (and done it), but this time I decided I wanted the whole picture. A package diagram wouldn't give the me the level of detail I'm wanting at this time. I can see how the size and level of detail can be confusing. Once I have decided on the final design of a package, I'll put it into it's own file, and have it represented by a package in this one. The Controller is the first probable candidate for this.
It's not complete yet, for example I haven't included a View reference in the Tokens. This because I haven't spent much thought on the View yet.
The idea for the Controller is to provide a rigid frame for all application commands. Every single command is encapsulated in a Command object, producing a status, with which the Application Controller decides which Token it needs next, based on XML configuration, assisted by Controller_Factory. References to the model are provided through a Context object, which is reused for multiple Commands. I'm planning on a Transaction Manager, so Context objects would only provide the Commands with the actual domain objects. The Context objects would be responsible for starting/resuming transactions. I still have some decisions to make regarding input during a transaction spanning multiple requests.
So basically a client developer would make concrete Context and Command classes, provide them with appropriate status codes, and create an XML configuration file to dictate application flow. Controller_Factory would use a serialized Token cache to avoid endless XML parsing.
I like the registry you've spec'd but I wonder what is the purpose of the sleep and wakeup methods? At least I don't understand there purpose so far as you're running a single thread at a time. If you imagine running multiple threads (is that even possible in PHP?) then I see the reason why they've been included.
I've abstracted __sleep() into the DomainObject abstract because I'm lazy.
class Backbone_Tools {
/**
* Returns array of an objects property names, convenient for __sleep()
*
* @param object $obj
* @return array
*/
public static function getObjectPropNames($obj){
$refl = new ReflectionObject($obj);
$propNames = array();
foreach ($refl->getProperties() as $reflProp){
$propNames[] = $reflProp->getName();
}
return $propNames;
}The Application Registry will use serialization, a simple Serialized LOB. Same goes for the Session Registry. And no, PHP doesn't have threading support, closest one can come is utilizing the Process Control functions. But that isn't available on most shared hosts, so I'm leaving them well alone. Concurrency is always an issue in web applications, not just multi-threaded ones.
With that said I did take a look and it seems you're starting a large project. I say this looking at your domain model, which has most of the usual suspects. May I ask what data wrapper you plan to use? If you're going to be implementing one from scratch you may be interested in putting your effort together with mine and my partner's, as we're currently developing an ORM/persistance layer in PHP.
I still have a lot of thinking to do on the Data Layer. Only thing I've really decided on is that I want to use Unit of Work Controller [PoEAA: 187]. I've named it Data_Controller, because it sounds a little more catchy
. I don't want a client developer to worry about marking objects dirty etc, as would be required with caller or object registration. Sure it's a little more expensive, but I'm sure I can minimize the cost. I still need a lot more thought on Data Mapping, in particular Foreign Key Mapping.
I'd be interested in trading thoughts on ORM, and joining efforts sounds perfect to me, if we can come to an agreement on the approach. Send me a PM, we can talk a little about this in private.
Finally, don't bother with the View for now, as I said, I haven't really spent any thought on it. In fact it's just something very old I reverse engineered, it defies the MVC paradigm as in it's current state it would require Command objects to register updates.
