NYCPHP Meetup

[Justin Demaris]

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 <ircmaxell at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20120507/8b6dd0b2/attachment.html>