-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi,
thanks benjamin for reminding us what the model really is. i think its a good idea to put the actual code under MyBundle/Persistence . when the same code can be used for all persistence layers, we do not need to further namespace by technology, otherwise we add the technology names. one question: how do you handle instantiation of your persistence objects in such a situation? i think we should come to an agreement for the short term future to avoid the name clashes richard brought up and improve understanding. in the long run, it would be great to find out how to further reduce persistence layer specific classes, but that won't happen overnight. (i am not saying we should not discuss it now - the sooner the better - but we still need a short term solution) cheers,david Am 29.03.2012 15:04, schrieb Benjamin Eberlei: > 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 > <thoma...@redpill-linpro.com <mailto:thoma...@redpill-linpro.com>> 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 <http://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 symfony-devs@googlegroups.com > <mailto:symfony-devs@googlegroups.com> > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > <mailto:symfony-devs%2bunsubscr...@googlegroups.com> > 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 symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en - -- Liip AG // Agile Web Development // T +41 26 422 25 11 CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk96sw0ACgkQqBnXnqWBgIvZ5QCgonqHY7cvcrGt81UjyzK/LcZW EpUAnR66+ACewWGgp84T6p1a8aJWPweT =d/UY -----END PGP SIGNATURE----- -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
