Re: [fw-general] Best practice to share identity map across mappers? Static registry?

[Marian Meres]

Hello Hector,

> Is there a reason you don't want to go with a static identity map?

Well, I consider usage of static map in this case most simple and even correct.

But as I'm in the planning phase and always questioning the design, I
want to make sure I'm doing it the correct way. And after reading many
posts on this topic recently from people I consider much more
experienced (among others mainly Matthew's), it looks like trying to
avoid the static registry usage may be worth the energy. Perhaps even
if I am unable to clearly see the reasons (other than testing)...

Thanks.

M.

Some notes here: http://misko.hevery.com/code-reviewers-guide/


On Mon, Aug 31, 2009 at 6:34 AM, Hector Virgen  wrote:
>
> Marian,
> A static identity map is the way to go. Page 291 of Php objects, patterns, 
> and practice by Matt Zandstra demonstrates how to build a simple but 
> effective identity map. Is there a reason you don't want to go with a static 
> identity map?
> --
> Hector
>
>
> On Sun, Aug 30, 2009 at 10:32 AM, Marian Meres  wrote:
>>
>> Hello Benjamin,
>>
>> thank you... but either I can't follow, or I must not have described 
>> properly the question. Because I do not understand how the factory could 
>> help you to share the map, unless you do not share the factory then...
>>
>> Example:
>>
>> class MapperFactory
>> {
>>    protected $_identityMap;
>>    public function create($name)
>>    {
>>        $mapperClass = $this->_somePrefix . $name;
>>        $mapper = new $mapperClass();
>>        $mapper->setIdentityMap($this->getIdentityMap($name));
>>        return $mapper;
>>    }
>> }
>>
>> // somewhere in log on (user service)
>> $mapperFactory = new MapperFactory();
>> $userMapper = $mapperFactory->create('user');
>> $user = $userMapper->find(1); // find also saves the user identity.
>>
>> // somewhere in article model
>> class Article
>> {
>>    // lazy load author
>>    public function getAuthor()
>>    {
>>        if (null == $this->_author) {
>>            $mapperFactory = new MapperFactory();
>>            $userMapper = $mapperFactory->create('user');
>>            $this->_author = $userMapper->find($this->_authorId);
>>        }
>>        return $this->_author;
>>    }
>> }
>>
>> My question is, how to design the whole thing so that the later model can 
>> reuse the identity set in the log on service (if applicable), while trying 
>> to avoid implementing static something somewhere. My understanding is, that 
>> without introducing new "domain superlayer" this could hardly be done, but 
>> is it worth it then? Why just not live with the static, with proper 
>> resetings (I know the test issues).
>>
>> Zend_Application is nice example where it works well (the good, non static 
>> container), but is this approach applicable to pure domain classes, where 
>> there is no front controller to pull the container from?
>>
>> Thank you again.
>>
>> And, BTW, respect for the Zend_Entity work! Very inspiring.
>>
>> Regards,
>> M.
>>
>>
>> On Sun, Aug 30, 2009 at 5:17 PM, Benjamin Eberlei wrote:
>> > hello,
>> >
>> > If you dont instantiate your mappers through a factory you probably will 
>> > have
>> > lots of work to do if you dont make access to the identity map global via a
>> > static method.
>> >
>> > greetings,
>> > Benjamin
>> >
>> > On Sunday 30 August 2009 04:58:32 pm Marian Meres wrote:
>> >> Hi All,
>> >>
>> >> I have many domain models where each has its own data mapper. These
>> >> mappers are spread across many places as a) services use mappers, b)
>> >> mapper x uses mapper y, c) and even models use mappers (only in the
>> >> case of lazy loading).
>> >>
>> >> I want mappers to utilize the identity map pattern (which is itself
>> >> pretty straightforward). I guess the whole pattern makes more sense
>> >> when used as a shared map across the mappers rather than for each to
>> >> have its own.
>> >>
>> >> Since the mappers usage (and instantiation) is wide spread (at least
>> >> in my case), the only solution I could think of is always a sort of a
>> >> static one (either through static members, or static "managers", or
>> >> even some injectable containers which default to static
>> >> Zend_Registry).
>> >>
>> >> What would you suggest, other than the static way?
>> >>
>> >> Thank you in advance.
>> >>
>> >> M.
>> >
>> >
>> > --
>> > Benjamin Eberlei
>> > http://www.beberlei.de
>> >
>>
>

Re: [fw-general] Best practice to share identity map across mappers? Static registry?

[Hector Virgen]

Marian,
A static identity map is the way to go. Page 291 of Php objects, patterns,
and 
practiceby
Matt Zandstra demonstrates how to build a simple but effective
identity
map. Is there a reason you don't want to go with a static identity map?

--
Hector


On Sun, Aug 30, 2009 at 10:32 AM, Marian Meres wrote:

> Hello Benjamin,
>
> thank you... but either I can't follow, or I must not have described
> properly the question. Because I do not understand how the factory could
> help you to share the map, unless you do not share the factory then...
>
> Example:
>
> class MapperFactory
> {
> protected $_identityMap;
>public function create($name)
> {
>$mapperClass = $this->_somePrefix . $name;
> $mapper = new $mapperClass();
>$mapper->setIdentityMap($this->getIdentityMap($name));
> return $mapper;
>}
> }
>
> // somewhere in log on (user service)
> $mapperFactory = new MapperFactory();
> $userMapper = $mapperFactory->create('user');
> $user = $userMapper->find(1); // find also saves the user identity.
>
> // somewhere in article model
> class Article
> {
>// lazy load author
> public function getAuthor()
>{
> if (null == $this->_author) {
>$mapperFactory = new MapperFactory();
> $userMapper = $mapperFactory->create('user');
>$this->_author = $userMapper->find($this->_authorId);
> }
>return $this->_author;
> }
> }
>
> My question is, how to design the whole thing so that the later model can
> reuse the identity set in the log on service (if applicable), while trying
> to avoid implementing static something somewhere. My understanding is, that
> without introducing new "domain superlayer" this could hardly be done, but
> is it worth it then? Why just not live with the static, with proper
> resetings (I know the test issues).
>
> Zend_Application is nice example where it works well (the good, non static
> container), but is this approach applicable to pure domain classes, where
> there is no front controller to pull the container from?
>
> Thank you again.
>
> And, BTW, respect for the Zend_Entity work! Very inspiring.
>
> Regards,
> M.
>
>
>
> On Sun, Aug 30, 2009 at 5:17 PM, Benjamin Eberlei
> wrote:
> > hello,
> >
> > If you dont instantiate your mappers through a factory you probably will
> have
> > lots of work to do if you dont make access to the identity map global via
> a
> > static method.
> >
> > greetings,
> > Benjamin
> >
> > On Sunday 30 August 2009 04:58:32 pm Marian Meres wrote:
> >> Hi All,
> >>
> >> I have many domain models where each has its own data mapper. These
> >> mappers are spread across many places as a) services use mappers, b)
> >> mapper x uses mapper y, c) and even models use mappers (only in the
> >> case of lazy loading).
> >>
> >> I want mappers to utilize the identity map pattern (which is itself
> >> pretty straightforward). I guess the whole pattern makes more sense
> >> when used as a shared map across the mappers rather than for each to
> >> have its own.
> >>
> >> Since the mappers usage (and instantiation) is wide spread (at least
> >> in my case), the only solution I could think of is always a sort of a
> >> static one (either through static members, or static "managers", or
> >> even some injectable containers which default to static
> >> Zend_Registry).
> >>
> >> What would you suggest, other than the static way?
> >>
> >> Thank you in advance.
> >>
> >> M.
> >
> >
> > --
> > Benjamin Eberlei
> > http://www.beberlei.de
> >
>
>

Re: [fw-general] Best practice to share identity map across mappers? Static registry?

[Marian Meres]

Hello Benjamin,

thank you... but either I can't follow, or I must not have described
properly the question. Because I do not understand how the factory could
help you to share the map, unless you do not share the factory then...

Example:

class MapperFactory
{
   protected $_identityMap;
   public function create($name)
   {
   $mapperClass = $this->_somePrefix . $name;
   $mapper = new $mapperClass();
   $mapper->setIdentityMap($this->getIdentityMap($name));
   return $mapper;
   }
}

// somewhere in log on (user service)
$mapperFactory = new MapperFactory();
$userMapper = $mapperFactory->create('user');
$user = $userMapper->find(1); // find also saves the user identity.

// somewhere in article model
class Article
{
   // lazy load author
   public function getAuthor()
   {
   if (null == $this->_author) {
   $mapperFactory = new MapperFactory();
   $userMapper = $mapperFactory->create('user');
   $this->_author = $userMapper->find($this->_authorId);
   }
   return $this->_author;
   }
}

My question is, how to design the whole thing so that the later model can
reuse the identity set in the log on service (if applicable), while trying
to avoid implementing static something somewhere. My understanding is, that
without introducing new "domain superlayer" this could hardly be done, but
is it worth it then? Why just not live with the static, with proper
resetings (I know the test issues).

Zend_Application is nice example where it works well (the good, non static
container), but is this approach applicable to pure domain classes, where
there is no front controller to pull the container from?

Thank you again.

And, BTW, respect for the Zend_Entity work! Very inspiring.

Regards,
M.


On Sun, Aug 30, 2009 at 5:17 PM, Benjamin Eberlei
wrote:
> hello,
>
> If you dont instantiate your mappers through a factory you probably will
have
> lots of work to do if you dont make access to the identity map global via
a
> static method.
>
> greetings,
> Benjamin
>
> On Sunday 30 August 2009 04:58:32 pm Marian Meres wrote:
>> Hi All,
>>
>> I have many domain models where each has its own data mapper. These
>> mappers are spread across many places as a) services use mappers, b)
>> mapper x uses mapper y, c) and even models use mappers (only in the
>> case of lazy loading).
>>
>> I want mappers to utilize the identity map pattern (which is itself
>> pretty straightforward). I guess the whole pattern makes more sense
>> when used as a shared map across the mappers rather than for each to
>> have its own.
>>
>> Since the mappers usage (and instantiation) is wide spread (at least
>> in my case), the only solution I could think of is always a sort of a
>> static one (either through static members, or static "managers", or
>> even some injectable containers which default to static
>> Zend_Registry).
>>
>> What would you suggest, other than the static way?
>>
>> Thank you in advance.
>>
>> M.
>
>
> --
> Benjamin Eberlei
> http://www.beberlei.de
>

Re: [fw-general] Best practice to share identity map across mappers? Static registry?

[Benjamin Eberlei]

hello,

If you dont instantiate your mappers through a factory you probably will have 
lots of work to do if you dont make access to the identity map global via a 
static method.

greetings,
Benjamin

On Sunday 30 August 2009 04:58:32 pm Marian Meres wrote:
> Hi All,
>
> I have many domain models where each has its own data mapper. These
> mappers are spread across many places as a) services use mappers, b)
> mapper x uses mapper y, c) and even models use mappers (only in the
> case of lazy loading).
>
> I want mappers to utilize the identity map pattern (which is itself
> pretty straightforward). I guess the whole pattern makes more sense
> when used as a shared map across the mappers rather than for each to
> have its own.
>
> Since the mappers usage (and instantiation) is wide spread (at least
> in my case), the only solution I could think of is always a sort of a
> static one (either through static members, or static "managers", or
> even some injectable containers which default to static
> Zend_Registry).
>
> What would you suggest, other than the static way?
>
> Thank you in advance.
>
> M.


-- 
Benjamin Eberlei
http://www.beberlei.de