Stem 2.0 - Move to popo's

[acuthbert]

Collections, relationships and intersections are corners stones of Stem however there is a continued momentum away from 'smart' models and event driven business logic in favour of declarative forward calculating logic using simpler data containers - entities or POPOs (plain old PHP objects).

Our models are heavy and have provision for a lot of features that are no longer recommended practice. They hide too much behaviour in their internals meaning the consequence of changing properties can't be predicted. The event driven nature also means that cascade effects (one small change causing a performance draining rain of database hits as model after model takes the opportunity to update itself). Often this behaviour is required - those models do need updated - but perhaps more often they are unintended consequences of one small action.

The biggest problem is a lack of control - the developer can't reliably see or predict what's going to happen when they change a property or save the model.

I'm proposing a shift to making Stem hydrate simple POPOs. This would retain all of the power of collections, intersections, schemas and relationships but provide a much lighter vehicle for data movement.

This would also allow the main business logic for an application to be framework agnostic and require no additional plumbing to migrate those objects in and out of the framework.

No doubt there are many other suggestions for improving the expressiveness and efficiency of Stem - please get all your ideas down here, preferrably with code snippets of how you would see that change being worked out in practice.

[acuthbert]

Hi guys - this has been open for a while. I'll throw some ideas on here, but please feel free to disagree or suggest alternatives.

Repositories

Repositories in Stem 1 where the means of shuffling data into and out of models and for interpreting filters and intersections etc.

In Stem 2 I propose that each record type gets it's own repository. It would now house the functionality of schema detection and migration:

class SalesOrders extends MySqlRepository
{
    public function createSchema() // as Model used to do
}

Loading a model

$salesOrder = SalesOrders::findByIdentifier($salesOrderId);
$salesOrder = SalesOrders::findFirst(...);
$salesOrder = SalesOrders::findLast(...);

Creating a collection

Repositories would also now be the source of making a collection:

$list = SalesOrders::all();
$list = SalesOrders::find(...);

Model POPOs

The base Model class would only be a marker of type, and supply no functionality (it could and maybe should? be just an interface?)

class SalesOrder extends Model
{
      /**
      * @var string
      */
      public $orderNumber;
}

Question - plain old public fields or getter/setters?

[acuthbert]

Storing a model

SalesOrders::store($myNewSalesOrder);

[samnotsowise]

Question - plain old public fields or getter/setters?

I think it'd need to be public fields, otherwise the schema would need to know which setters to call to populate the object. I'd prefer Stem stipulate as little as possible if the goal is to work with "plain" objects. IMO the schema should even be taking care of the "which field is the id" question

[acuthbert]

Sure agreed - I suppose without any stipulation stem could look for either a public field or a setter - but yes we've found before that code like that very often ends up adding big performance penalties for large loops etc.

[acuthbert]

Filtering

How about this?

$matches = SalesOrders::find('Despatched' => true)
                      ->and('Value' => greaterThan(10));