Fixture loading should be done through a use case

[johnkary]

Marcello, what are your thoughts on requiring loading fixtures to utilize a use case service?

For example, LoadProjectManagers creates ProjectManager entities. This could be encapsulated in a use case CreateProjectManager. Should that service be used to create and persist the new ProjectManager entity in a fixture class? Or is loading a ProjectManager fixture its own use case?

    public function load(ObjectManager $manager)
    {
        $users = ['everzet' => 'qwerty'];
        foreach ($users as $username => $password) {
            $pm = $this->container->get('use_case.create_project_manager')->createProjectManager($username, $password);
            $this->addReference('project_manager.' . $username, $pm);
        }
    }

Your fixture class then does little more than list the fixture users you wish to create then leverage the use cases service. The fixture class could of course still use setReference() to coordinate with other fixtures, but it stays within its single responsibility.

The lifecycle of creating a ProjectManager would then be consistent across the application, no matter if the ProjectManager were created in the Controller, an interactive Command, or in this case a Fixture. This includes how a User's password is encoded. You would not want your fixture-loaded ProjectManager users to have their passwords encoded differently than those created through a Controller.

OR do you consider DataFixtures a very focused use case themselves that load raw entities into the database? Perhaps your CreateProjectManager service dispatches an event whose listener emails the ProjectManager user a welcome email. You certainly would not want a fixture class triggering a real email to anyone?

What do you think?