NYCPHP Meetup

[Anthony Ferrara]

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