Hi,
It's hard to come up with valuable feedback for such a complex topic, but after reading and thinking for a while there are a couple of things that are very clear for me.
First off, the thing I like the most about using a unit of work is that I don't need to manually save every single object I load on a request (or process for cron jobs).
For CRUD type applications -like CMS's- that is not a big gain since your business logic is just changing and saving content. In my case, I'm working on a system that is growing in complexity over time in a way that I often need to update different objects inside a single action, using Facades for most cases. Take this case as an irresponsibly simple example:
Suppose I need to send an email to large set of affiliates, filtering on the kind of content they agreed to receive.
PHP Code:
$notification = new Notification ($subject, $content, $optInOptions);
$broadcaster = new Broadcaster();
$broadcaster->send($notification);
Class Broadcaster {
function send($notification) {
$matches = $affiliateFinder->findMatching($notification->getOptInOptions());
foreach ($matches as $affiliate) {
$affiliate->receive($notification);
}
$notification->updateStatus('sent');
}
}
This code is ignoring persistance at the moment, but If I want to persist all changes using a DAO or a Mapper, I have to add that logic to the process, making the code look a little bit like this:
PHP Code:
// after the notification was sent
$notification->save();
// or
$notificationMapper->save($notification);
// and the same for each affiliate
$affiliate->save();
And the logic can get worse when you start to add features. I don't like how the code gets cluttered with a lot of saving stuff that isn't really business logic.
With a UoW solution the client code stays almost the same, and you would only require the UoW to start() at the top and commit() at the end (ideally). This is VERY different to the solutions we have at the moment for PHP, so is not really re-inventing the wheel, but I do believe that we can use what's alredy done.
In particular, we could be better off if we register objects to the UoW from the domain objects and/or finders, as in:
PHP Code:
Class notification {
function __construct($subject, $text, $options) {
$this->subject = $subject;
$this->text = $text;
$this->options = $options;
UoW::registerNew($this);
}
function setText($text) {
$this->text = $text;
UoW::registerDirty($this);
}
// ...
}
Which could be done very neat when using AoP to generate the registering code. This leads me to my second point.
I have not used Metastorage yet, but I did went and see the tutorials and tried to understand what it is all about. Even though I wasn't thorough reading and testing stuff, I'd suggest to start from there since the code generation seems to be pretty mature and relationships are very well implemented.
I think I read it uses AoP, so the question is... would it be to hard to icorporate the UoW registering stuff as an aspect?
Originally Posted by mlemos
.
. I already have an OS project (SimpleTest) and project manage two others (Arbiter, SpamProofWiki). And then I had a son and now it's really fallen apart...
.
Bookmarks