I have been thinking about this problem before a lot, and my (highly experimental) current opinion with this mess:
1. Why did we develop all these data mappers, when we suggest users to differentiate between them AGAIN? (Ok this is excluding Propel - but you could still map active record to "real entities" using propel) 2. Why does everyone automatically assume that Model = Entities/Database Records. This is a highly dangerous opinion. 3. Even if Symfony is now by far the most perfect framework with regard to "not messing around in the my domain problems", i think its still to invasive (by default/conventions). The model is all the code that is related to the "domain" of the particular bundle/library. This includes, services, value objects, data transfer objects, validators and all this. In my recent applications all this code has been going into the folders: MyBundle/Model/Entity MyBundle/Model/Service MyBundle/Model/Validator MyBundle/Model/Repository MyBundle/Model/CustomNamespaces Now Entity/Repository here is not the term of Doctrine, but in the Domain Driven Design kind of way (even if the projects are not DD). Everything related to persistence however, and this includes DQL and such should be somewhere else, such as in MyBundle/Persistence/ORM/Repository. What does the MyBundle/Model/Repository namespace include? Just interfaces. Open questions: 1. Transaction management, i am trying to solve this with SimpleThingsTransactionalBundle, but i havent found the perfect (and simple!) solution yet. Its still experimental. 2. Going away from nesting the domain logic deep in a Symfony application, but nesting "a symfony" application as one endpoint of my "real" application code (unsymfony, or un-framework for that matter). 3. Making this "simple" and easy to use for developers. The current conventios have the advantage that they are very simple to follow and understand, just that they easily lead to undesired coupling. Research that keeps me up on this topic is the new "Data, Context, Interaction" movement and this talk by Uncle Bob: http://confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years On Thu, Mar 29, 2012 at 9:17 AM, Thomas Lundquist < [email protected]> wrote: > On Thu, Mar 29, 2012 at 08:53:30AM +0200, David Buchmann wrote: > > > > 1) i totally agree we have to avoid name clashes and will happily update > > the phpcr bundle documentation and the existing bundles to not use the > > Document namespace anymore, as soon as we agree on a naming scheme. > > i think i like the idea of a common top folder for all those persistence > > layers better than spreading the different types in the bundle root. it > > also makes it more obvious what this is about. what would you think of > > not using Persistence but just to use Model for the generic classes and > > create the backend-specific folders as subfolders of Model? like > > Model\PHPCR and so on. > > I thought about this aswell and it kinda sounds correct to do so but > what if the persistence stuff is more than one class? > > I use both a persistence object (which is the Entity in Doctrine) and > also a specific manager, usually per class, in my little orm-thignie. > > This is also typical how Zend Framework and others do this (Model, > Mapper, Maager) and we should make sure this way of doing it can > be applied. > > It may be totally acceptable to have Model/Perfoo/Frog.php, FrogManager.php > and so on like how Entity has both the Entity class and the repository > (Which really annoys me at least). > > But does it show the separation well enough? Me thinks not. I'd rather > have two separate directories from bundle-root. Model and <something>/ > > > 2) afaik when not using the annotation mapping but xml or yml mapping, > > it should be possible to avoid persistence specific models alltogether, > > at least in many cases. what are good examples of actually needing > > persistence specific models? > > This is ohh so true but it does apply more magic. On the other hand, > we have passed the "too much magic" border long time ago, even with > the new versions of both Doctrine and Symfony. > > So, why not? > > It's dependant on the orm/odm/manager if this is possible or not but > I guess it can be done. > > > Thomas. > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
