You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is extracted from #72 because it is scheduled for a later version of the event store.
We should first think about the best way to implement the factory.
In proophessor we had a RepositoryAbstractFactory which implemented Zend\ServiceManager\AbstractFactoryInterface. For a container-driven factory there is no guarantee that the requested service name is passed to the factory. So we cannot create a repository for a specific aggregate type. This makes the factory useless.
For now users need to write their own factories. With the information from the docs this task should not be very complex.
One way I can think of is to implement the factory as a container. Interop\Container defines a Delegate lookup feature. So the factory could act as a container. Factory::has would be similar to AbstractFactoryInterface::canCreateServiceWithName and Factory::get would be similar to AbstractFactoryInterface::createServiceWithName. To fetch repository dependencies like the event store or stream strategy the factory would use a delegate container.
Problem is: I don't know if this is useful when working with Zend\ServiceManager. It has also a delegate feature but I never used it before and I don't know if it is compatible with container-interop.
The text was updated successfully, but these errors were encountered:
ZF2 delegate is not compatible with container interop.
Factory::has and AbstractFactoryInterface::canCreateServiceWithName have completely different purposes.
That said, it doesn't make any sense to go this way.
I would propose 2 things
Provide a ZF2-Abstract-Service Factory to use in conjunction with ZF2 projects (incl. documentation that you can only use it in a ZF2 world).
Provide a Factory which is an abstract class and can should get extended in order to be usefull. Most aggregate repository setup is the same for all repos, so in the userland code you need only to take care of some small thing, the rest could be done in the abstract class (factory) we provide.
I love the ZF2 Abstract Factories because you can load the config by name. I think it could be useful to extract framework factories to an extra repo. So we can create also a Symfony/Laravel ... bridge.
👍 for framework bridges. I did this in the past with proophessor and would like to have explicit repos like prooph/zend-mvc-bridge, prooph/symfony-bridge, prooph/laravel-bridge and so on in the future.
This is extracted from #72 because it is scheduled for a later version of the event store.
We should first think about the best way to implement the factory.
In proophessor we had a RepositoryAbstractFactory which implemented
Zend\ServiceManager\AbstractFactoryInterface
. For a container-driven factory there is no guarantee that therequested service name
is passed to the factory. So we cannot create a repository for a specific aggregate type. This makes the factory useless.For now users need to write their own factories. With the information from the docs this task should not be very complex.
One way I can think of is to implement the factory as a container. Interop\Container defines a Delegate lookup feature. So the factory could act as a container.
Factory::has
would be similar toAbstractFactoryInterface::canCreateServiceWithName
andFactory::get
would be similar toAbstractFactoryInterface::createServiceWithName
. To fetch repository dependencies like the event store or stream strategy the factory would use adelegate container
.Problem is: I don't know if this is useful when working with
Zend\ServiceManager
. It has also a delegate feature but I never used it before and I don't know if it is compatible with container-interop.The text was updated successfully, but these errors were encountered: