This PR will solve #18 and #9. Atm i don't think that we need a configuration at all. The Persister will get its own supports(type)method to decide if they are responsible for a specific type. So they should do their work to persiste a specific resource. The UoWwill get a persister as a chain, with the same interface as the persister. So the UoW will talk to the chain same as it would talk to a singe persister. The chain will loop throug the registered persisters and ask them for supports(type) . The first match will get the work.
Tasks:
[x] create and test the persister chain based on types
[x] implement supports() method on the given persister
[ ] let UoW use the persister chain
[ ] UoW interface extended to use type, which can default
[ ] register both base persister on the module app
This PR will solve #18 and #9. Atm i don't think that we need a configuration at all. The Persister will get its own
supports(type)method to decide if they are responsible for a specific type. So they should do their work to persiste a specific resource. TheUoWwill get a persister as a chain, with the same interface as the persister. So theUoWwill talk to the chain same as it would talk to a singe persister. The chain will loop throug the registered persisters and ask them forsupports(type). The first match will get the work.Tasks:
supports()method on the given persisterUoWuse the persister chainUoWinterface extended to use type, which can default