/** * This is the standard example found at * http://http://symfony.com/doc/2.0/bundles/DoctrineFixturesBundle/ * With a few comments added **/ class LoadUserData implements FixtureInterface { public function load(ObjectManager $manager) { // this is a typical approach // to making a doctrine fixture $userAdmin = new User(); $userAdmin->setUsername('admin'); $userAdmin->setPassword('test'); $manager->persist($userAdmin); $manager->flush(); $this->addReference('admin-user', $userAdmin); // but, if you try this approach $userAdmin2 = new \genericUserClass(); // not a doctrine entity, not namespaced $userAdmin2->setName('admin'); $userAdmin2->setPassword('test'); $userAdmin2->saveUsingSomeCustomMethod(); $this->addReference('admin-user-2', $userAdmin2); // NOPE! ERROR! } }
I understand the strictness. I understand that it makes logical sense to restrict a doctrine fixture generator to passing around only doctrine entities.
But logical sense doesn't always equal intuitive sense and, if the class has an interface that is acceptable to doctrine references, then it should be allowed.
This strictness makes it more difficult to refactor legacy systems into Symfony2. Existing classes, heavy with business logic, become more difficult to use. I find that I have to do something like:
class LoadUserData implements OrderedFixtureInterface,ContainerAwareInterface { public function load(ObjectManager $manager) { $userAdmin2 = new \genericUserClass(); // not a doctrine entity $userAdmin2->setName('admin'); $userAdmin2->setPassword('test'); $userAdmin2->saveUsingSomeCustomMethod(); $doctrineUserAdmin2 = $manager->getRepository("CoreBundle:UserClass") ->findById($userdmin2->getId()); $this->addReference('admin-user-2', $doctrineUserAdmin2 ); } }
Certainly there are plenty of arguments why you should stick to only doctrine entities. But it inevitably makes it harder to structure and integrate symfony2 and legacy systems.
Just my two cents. Which is what this opinion is probably worth.
No comments:
Post a Comment