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:
Locked
