Thanks again for the feedback Anthony :) I really have to look into this Data Mapper approach more. I like the sound of your architecture a lot.
On Mon, May 7, 2012 at 11:09 AM, Anthony Ferrara <ircmax...@gmail.com>wrote: > Justin, > > > My issue ends up being that we can't always expect everyone on the team > > (it's a pretty large team) to deeply understand the proper way of doing > > everything. I want this feature as a way to help prevent people from > > shooting themselves in the foot, so yes, I do want this all of the time. > I > > have seen a lot of code that pretty much assumes the ORM objects are just > > like any other variable and the objects can be instantiated very often to > > make the logic of a for loop simpler. > > We could debate this point, but I think it's a bit off topic. My > counter would be simply that "If you can't trust your own developers, > you can't solve any other problems"... > > > See above. Retraining everyone is not an option, and I've seen a lot of > > people assume that if they aren't accessing the data, then the object > should > > be a very cheap call and they instantiate it frivolously. > > Would you rather train someone and risk they leave, or not and risk they > stay? > > > We can all argue > > that you need to know your platform in detail in order to really use it > > right and it certain things will be better in optimal cases, but these > are > > the variables I have to work with. The other issue is that at small > scale, > > most of the time the performance is still quite acceptable, but as the > > product grows and the scale grows, these cases become more obvious. These > > kind of lazy loads enable me to pass objects around to functions that may > > need them, but only incur the database hit if the function does end up > > needing them. > > Well, but I'd counter there that by making things lazy loading, you're > putting a HUGE burdon on your caching layer. Not only does it need to > know about the normal objects, but also about all the micro-queries > your executing to do the lazy loading. Which means that when you need > to invalidate the cache for a record, there are hundreds of possible > queries instead of a handful. > > Not saying that either approach is right or wrong. Just that each has > pros and cons. I'd much rather have a simple, non-lazy loading app > that I needed to scale rather than one with the complexities of lazy > loading... > > > > When working with Mongo, do you just pass around the stdClass / array > > representation of the document to do work on it? Do you do anything at > the > > code level to force a standard attribute list for it? > > That's the job that my data mapper does for me. It takes the stdClass > and maps it to my business objects. So my business objects have the > enforced properties and schema, and the data mapper does the > translation (knowing about both sides). Nothing in the model layer or > above (view, controller, etc) has any knowledge of the data storage > format, or how to create the business objects. That's the role the > data mapper plays in my applications. > > Anthony > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation >
_______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
