--
Hector Virgen
I put the Unit of Work and the Identity Map in the same object. Then each model implements an interface that allows it look up it's mapper when the Unit of Work/Identity Map object asks it to interact with the data sources. The method in the Unit of Work/Identity Map object looks something like this:public function performOperations(){foreach($this->objList as $obj){if( $this->isDirty( $obj ) ) {$obj->mapper()->update( $obj );}//check for new//check for delete}}//performOperations$this->dirty holds a list of all objects that have modified the data they took from their data source. $obj's mapper() function returns an object from a factory that handles all of the data source interactions.David KanenwisherOn Tue, Aug 24, 2010 at 10:40 AM, Hector Virgen <djvirgen@gmail.com> wrote:
I agree, an Identity Map is definitely the way to go and compliments caching. But I haven't had any luck implementing the Unit of Work pattern. Do you place the Unit of Work in its own class or does each model implement it?
--
Hector VirgenSr. Web DeveloperWalt Disney Parks and Resorts Online
On Tue, Aug 24, 2010 at 6:46 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
We've managed to avoid dependency issues by creating an object that uses the Identity Map and Unit of Work patterns. The Identity Map keeps track of all the objects as we pull them from the database so we don't have to worry about duplicating objects. The Unit of Work functions as intermediary between the model and the functions used to retrieve and store data from our data sources. When we call the Unit of Work to do it's thing it goes through the list of objects in the Identity Map and performs any operations which need to be done on the objects. This allows us to create unit tests which test how our model functions and then separately test the methods they are taken from and stored to our data source. Of course, all of this is also completely separate from the controller ensuring we have a thin controller and a fat model.David KanenwisherOn Mon, Aug 23, 2010 at 8:59 AM, Hector Virgen <djvirgen@gmail.com> wrote:
It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?
--
Hector Virgen
Sent from my Droid XOn Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>
没有评论:
发表评论