Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a factory for the AggregateRepository #89

Closed
codeliner opened this issue Aug 25, 2015 · 4 comments
Closed

Provide a factory for the AggregateRepository #89

codeliner opened this issue Aug 25, 2015 · 4 comments
Assignees
Milestone

Comments

@codeliner
Copy link
Member

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.

@codeliner codeliner added this to the 5.1 Release milestone Aug 25, 2015
@prolic
Copy link
Member

prolic commented Aug 26, 2015

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

  1. 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).
  2. 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.

@codeliner
Copy link
Member Author

sounds good 👍 That will be a good addition for 5.1

@sandrokeil
Copy link
Member

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.

@codeliner
Copy link
Member Author

👍 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.

@codeliner codeliner modified the milestones: 6.0 Release, 5.1 Release Sep 20, 2015
@codeliner codeliner self-assigned this Oct 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants