Zend\Db: TableGateway + RowGateway Improvements

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend\Db: TableGateway + RowGateway Improvements

ralphschindler
Hi all,

There are a number of changes in the RowGateway and TableGateway
implementation since beta3.

The most up to date versions of these components are located in my
branch here:

https://github.com/ralphschindler/zf2/tree/feature/db-tablegateway-improvements

First, I have moved implementations around between the
AbstractTableGateway and the TableGateway.  The abstract is the primary
source for the implementation of TableGateway lives, and the concrete
TableGateway object is the source of the constructor that allows
injecting the few dependencies that are needed to have a working TG object.

Also, I have added a "feature" feature to both TableGateway and
RowGateway.  What this allows is unlimited extension of the behaviors of
the TableGateway through registering "Feature" objects with the target
TableGateway object.  Currently, these features include:

   * ability for TableGateway's select to return RowGatewayObjects
   * ability of TableGatways to use a Master-Slave adapter pattern
   * ability to use EventManager in TableGateway objects
   * ability to use a global/static adapter in TableGateway objects
   * ability to populate columns information through Metadata obects

The few I've implemented are located here:

https://github.com/ralphschindler/zf2/tree/feature/db-tablegateway-improvements/library/Zend/Db/TableGateway/Feature

Here is a sample script showing how Features are injected into the
concrete TableGateway implementation:

https://github.com/ralphschindler/Zend_Db-Examples/blob/master/example-17.php

Please start to play with this.  The tests have been refactored to work
with theses improvements, and I will document and further unit test this
work this week for the upcoming beta4 release.

Catch me online in zftalk.2 for more information.

-ralph
Reply | Threaded
Open this post in threaded view
|

Re: Zend\Db: TableGateway + RowGateway Improvements

Tomáš Fejfar
I don't get it :( How is the behaviour different from using without the "Feature"?


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Db: TableGateway + RowGateway Improvements

ralphschindler
Ok, good question!

First, without using any of the Features, you have a very basic
TableGatway object.  It is still a very useful object, it just lacks
features.  Any time you want to add features to an existing class, your
options are to refactor the original implementation to accommodate the
feature, or extend the base implementation.  Extending the base
implementation is not an option as each new feature becomes
mutually-exclusive to use (you can't extend multiple classes at a single
time.)

The problem in ZF1 is there is an outstanding list of "new features"
that people wanted baked into Zend_Db_Table.  When you start adding
features directly to a single class a number of things happen: a) it
becomes harder to maintain and b) it starts to violate the Single
Responsibility Principle.

Zend\Db\TableGateway\Feature and the AbstractTableGateway offer an
architectural solution that will provide for infinite extension while
maintaining an easy to manage base class (code wise), and ensuring that
the addition of new features in the future don't break base-class
functionality.

For example, some developers simply want the TableGateway to interact
without returning RowGateway objects, others do not.  Some developers
want pre-insert validation on values, while others do not.  Some
developers want an EventManager instance to be privy to every action in
a TableGateway's workflow/lifecycle, others do not.  This architecture
allows for all of those situations, as well as situations/features,
we've yet to dream up (just implement the AbstractFeature object).

So, instead of loading the base implementation up with conditional logic
and all of these features (listed in the parent post), we build a simple
architectures that lets the feature code live in it's own
class/instance, and it can be injected/coupled with the base
implementation to achieve their goals.

Hope that answers your questions..

Try it out!

-ralph

On 5/21/12 6:20 AM, Tomáš Fejfar wrote:

> I don't get it :( How is the behaviour different from using without the
> "Feature"?
>
> On Mon, May 21, 2012 at 7:12 AM, Ralph Schindler
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     https://github.com/__ralphschindler/Zend_Db-__Examples/blob/master/example-__17.php
>     <https://github.com/ralphschindler/Zend_Db-Examples/blob/master/example-17.php>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Zend\Db: TableGateway + RowGateway Improvements

David Weinraub
On 05/21/2012 08:00 PM, Ralph Schindler wrote:

> Ok, good question!
>
> First, without using any of the Features, you have a very basic
> TableGatway object.  It is still a very useful object, it just lacks
> features.  Any time you want to add features to an existing class,
> your options are to refactor the original implementation to
> accommodate the feature, or extend the base implementation.  Extending
> the base implementation is not an option as each new feature becomes
> mutually-exclusive to use (you can't extend multiple classes at a
> single time.)
>
> The problem in ZF1 is there is an outstanding list of "new features"
> that people wanted baked into Zend_Db_Table.  When you start adding
> features directly to a single class a number of things happen: a) it
> becomes harder to maintain and b) it starts to violate the Single
> Responsibility Principle.
>
> Zend\Db\TableGateway\Feature and the AbstractTableGateway offer an
> architectural solution that will provide for infinite extension while
> maintaining an easy to manage base class (code wise), and ensuring
> that the addition of new features in the future don't break base-class
> functionality.
>
> For example, some developers simply want the TableGateway to interact
> without returning RowGateway objects, others do not.  Some developers
> want pre-insert validation on values, while others do not.  Some
> developers want an EventManager instance to be privy to every action
> in a TableGateway's workflow/lifecycle, others do not.  This
> architecture allows for all of those situations, as well as
> situations/features, we've yet to dream up (just implement the
> AbstractFeature object).
>
> So, instead of loading the base implementation up with conditional
> logic and all of these features (listed in the parent post), we build
> a simple architectures that lets the feature code live in it's own
> class/instance, and it can be injected/coupled with the base
> implementation to achieve their goals.
>
> Hope that answers your questions..
>
> Try it out!
>
> -ralph
>
> On 5/21/12 6:20 AM, Tomáš Fejfar wrote:
>> I don't get it :( How is the behaviour different from using without the
>> "Feature"?
>>
>> On Mon, May 21, 2012 at 7:12 AM, Ralph Schindler
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>    
>> https://github.com/__ralphschindler/Zend_Db-__Examples/blob/master/example-__17.php
>>    
>> <https://github.com/ralphschindler/Zend_Db-Examples/blob/master/example-17.php>
>>
>>
>
And more generally, it sounds like an interesting pattern/architecture
for keeping default implementations lean and "YAGNI'd" while allowing
flexibility and extensibility.

Perhaps a blog post that discusses the approach and how it could be
applied more generally by all of us how here in userland?

--
David Weinraub
[hidden email]
[hidden email]
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Zend\Db: TableGateway + RowGateway Improvements

Tomáš Fejfar
Thanks for the explanation Ralph. It makes more sense now. 
Reply | Threaded
Open this post in threaded view
|

Re: Zend\Db: TableGateway + RowGateway Improvements

xoops
In reply to this post by ralphschindler
If I understand correctly, is the FeatureSet an implementation of Decorator pattern?

On Mon, May 21, 2012 at 9:00 PM, Ralph Schindler <[hidden email]> wrote:
Ok, good question!

First, without using any of the Features, you have a very basic TableGatway object.  It is still a very useful object, it just lacks features.  Any time you want to add features to an existing class, your options are to refactor the original implementation to accommodate the feature, or extend the base implementation.  Extending the base implementation is not an option as each new feature becomes mutually-exclusive to use (you can't extend multiple classes at a single time.)

The problem in ZF1 is there is an outstanding list of "new features" that people wanted baked into Zend_Db_Table.  When you start adding features directly to a single class a number of things happen: a) it becomes harder to maintain and b) it starts to violate the Single Responsibility Principle.

Zend\Db\TableGateway\Feature and the AbstractTableGateway offer an architectural solution that will provide for infinite extension while maintaining an easy to manage base class (code wise), and ensuring that the addition of new features in the future don't break base-class functionality.

For example, some developers simply want the TableGateway to interact without returning RowGateway objects, others do not.  Some developers want pre-insert validation on values, while others do not.  Some developers want an EventManager instance to be privy to every action in a TableGateway's workflow/lifecycle, others do not.  This architecture allows for all of those situations, as well as situations/features, we've yet to dream up (just implement the AbstractFeature object).

So, instead of loading the base implementation up with conditional logic and all of these features (listed in the parent post), we build a simple architectures that lets the feature code live in it's own class/instance, and it can be injected/coupled with the base implementation to achieve their goals.

Hope that answers your questions..

Try it out!

-ralph


On 5/21/12 6:20 AM, Tomáš Fejfar wrote:
I don't get it :( How is the behaviour different from using without the
"Feature"?

On Mon, May 21, 2012 at 7:12 AM, Ralph Schindler
<[hidden email] <mailto:[hidden email]>> wrote:

   https://github.com/__ralphschindler/Zend_Db-__Examples/blob/master/example-__17.php
   <https://github.com/ralphschindler/Zend_Db-Examples/blob/master/example-17.php>






--

Taiwen Jiang (aka D.J.)

Build Xoops Engine
web and mobile application platform

CTO for EEFOCUS.com
Leading social platform for electronics professionals


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Db: TableGateway + RowGateway Improvements

weierophinney
Administrator
-- D. J. <[hidden email]> wrote
(on Wednesday, 23 May 2012, 11:38 AM +0800):
> If I understand correctly, is the FeatureSet an implementation of Decorator
> pattern?

It's more like subject/observer or potentially the visitor pattern.

> On Mon, May 21, 2012 at 9:00 PM, Ralph Schindler <[hidden email]>
> wrote:
>
>     Ok, good question!
>
>     First, without using any of the Features, you have a very basic TableGatway
>     object.  It is still a very useful object, it just lacks features.  Any
>     time you want to add features to an existing class, your options are to
>     refactor the original implementation to accommodate the feature, or extend
>     the base implementation.  Extending the base implementation is not an
>     option as each new feature becomes mutually-exclusive to use (you can't
>     extend multiple classes at a single time.)
>
>     The problem in ZF1 is there is an outstanding list of "new features" that
>     people wanted baked into Zend_Db_Table.  When you start adding features
>     directly to a single class a number of things happen: a) it becomes harder
>     to maintain and b) it starts to violate the Single Responsibility
>     Principle.
>
>     Zend\Db\TableGateway\Feature and the AbstractTableGateway offer an
>     architectural solution that will provide for infinite extension while
>     maintaining an easy to manage base class (code wise), and ensuring that the
>     addition of new features in the future don't break base-class
>     functionality.
>
>     For example, some developers simply want the TableGateway to interact
>     without returning RowGateway objects, others do not.  Some developers want
>     pre-insert validation on values, while others do not.  Some developers want
>     an EventManager instance to be privy to every action in a TableGateway's
>     workflow/lifecycle, others do not.  This architecture allows for all of
>     those situations, as well as situations/features, we've yet to dream up
>     (just implement the AbstractFeature object).
>
>     So, instead of loading the base implementation up with conditional logic
>     and all of these features (listed in the parent post), we build a simple
>     architectures that lets the feature code live in it's own class/instance,
>     and it can be injected/coupled with the base implementation to achieve
>     their goals.
>
>     Hope that answers your questions..
>
>     Try it out!
>
>     -ralph
>
>
>     On 5/21/12 6:20 AM, Tomáš Fejfar wrote:
>
>         I don't get it :( How is the behaviour different from using without the
>         "Feature"?
>
>         On Mon, May 21, 2012 at 7:12 AM, Ralph Schindler
>         <[hidden email] <mailto:[hidden email]>> wrote:
>
>            https://github.com/__ralphschindler/Zend_Db-__Examples/blob/master/
>         example-__17.php
>            <https://github.com/ralphschindler/Zend_Db-Examples/blob/master/
>         example-17.php>
>
>
>
>
>
>
>
>
> --
>
> Taiwen Jiang (aka D.J.)
>
> Build Xoops Engine
> http://www.xoopsengine.org
> web and mobile application platform
>
> CTO for EEFOCUS.com
> Leading social platform for electronics professionals
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc