On Thu, Mar 29, 2012 at 6:04 AM, Benjamin Eberlei <[email protected]>wrote:
> > 2. Why does everyone automatically assume that Model = Entities/Database > Records. This is a highly dangerous opinion. > > 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. > 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. > I'm in agreement with this. One of the things that gnawed at me a little when first looking at Symfony2/Doctrine2 was the reference to the persistence layer being referred to as the Model, since a model is business rules. An entity represents a domain object, which is one aspect of the set of business rules. Also, as entity classes are the way in which we interact with the database, we have no way to access a table's data without one, even though the entity class may technically not be considered part of a domain model. As an example, I may have a domain object Correspondence. One of it's fields could be $type, which points to a simple correspondence_type table (id, type_name, description, let's say...). I generally wouldn't consider CorrespondenceType to be an object in my problem domain, but the we seem to be forcing that type of thinking. Thus, some of the restructuring that we're discussing here makes a bit more sense in terms of organization and function. I think the organizational structure that Benjamin proposed is a worthy starting point, as is the standardizing that Richard brought forth in the original message. It also seems that commenters so far agree with the idea I mentioned of organizing under a Persistence directory. Johannes: Do you have any more thoughts on how you'd recommend doing a different structure for agnostic code? I have to admit that when I first starting looking at FOSUser, it seemed like I was chasing code over many classes, however once understood, it made sense. Common abstract model codes, with the concrete implementations for each abstraction. I agree that it's complex as-is, but sensible. I'm curious what other type of structure you're thinking. I think my first stab at doing agnostic code would have been roughly the same type of set up, and admittedly with that in already in mind (and not have having adequate time yet to mull over the problem), I'm so far stuck with starting to design an alternate way. Anyway, just some thoughts at 1AM. Interesting discussion and I'm looking forward to see where (if anywhere) this all goes. --mark -- 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
