4 ms·

I'm interested in your counter arguments too. I'm sure there is some component or aspect I'm missing.

PedroCandeias 15y ago
You'll get none from me. Funny reading your post, because it perfectly describes my own experience this year: starting to learn another language (ruby), then getting pulled right back into php for a big client project. And I also decided to ditch ORM and stick to PDO, which by the way is one hell of a library.
Ramone 15y ago
It's really all about factoring. You'll notice now that you have model logic in your controller. If you want to reuse that elsewhere, you'll first have to extract it to another class. That class is effectively a SQL generation library, except it's not useful in a general sense and it's not as well tested. The more you do this, the more you converge on reinventing a full blown ORM. I'm not saying there aren't downsides to ORMs, but the counter-arguments to SQL in your controller are pretty obvious.
- wvenable 15y ago
  I disagree. Yes, this should be refactored and placed in a model; but that would be something like Clients::getReadMetrics() that would contain the same SQL. I don't see that heading towards a full ORM or even remotely like SQL generation.
rmccue 15y ago
Couple of small things: you shouldn't `return ($var);`, since that returns the result of the statement `($var)`. Use `return $var;` instead, and return them by reference where possible. I also would have gone with naming consistent with PDO's (i.e. `halfCamelCase` rather than `lower_case`), but that's personal preference. Consistency would be nice though.
i_crusade 15y ago
Other commenters are complaining about SQL written in the controller. I don't see this as problem in general, depending on project and workflow it can be valid. OOP nit-picks will see a problem there, but OOP users know how to fix it right? Back on topic: I'm grieving with ORM for some time now. The main problem is that people doesn't really think about how appropriate an ORM solution over any other solution is. They learn one ORM system and use it everywhere. Worse, they do everything the ORM way, writing abstract ORM queries that should have been straight SQL (for readability). And you know what? Those people (or projects) are fire-and-forget. They work on a project for few month and then they're gone. They don't have experience with projects that run several years and all those problems tied to it. I think ORM (or full-stack framework) prototyping is much faster than straight SQL - within it's limitations. But for long term projects it's likely toxic. So in my opinion, ORM is pretty good for prototyping or low maintenance projects, or just prototypes. Considering your past it's learning curve.

You'll get none from me. Funny reading your post, because it perfectly describes my own experience this year: starting to learn another language (ruby), then getting pulled right back into php for a big client project. And I also decided to ditch ORM and stick to PDO, which by the way is one hell of a library.

Ramone 15y ago

It's really all about factoring. You'll notice now that you have model logic in your controller. If you want to reuse that elsewhere, you'll first have to extract it to another class. That class is effectively a SQL generation library, except it's not useful in a general sense and it's not as well tested. The more you do this, the more you converge on reinventing a full blown ORM. I'm not saying there aren't downsides to ORMs, but the counter-arguments to SQL in your controller are pretty obvious.

wvenable 15y ago
I disagree. Yes, this should be refactored and placed in a model; but that would be something like Clients::getReadMetrics() that would contain the same SQL. I don't see that heading towards a full ORM or even remotely like SQL generation.

rmccue 15y ago

Couple of small things: you shouldn't `return ($var);`, since that returns the result of the statement `($var)`. Use `return $var;` instead, and return them by reference where possible. I also would have gone with naming consistent with PDO's (i.e. `halfCamelCase` rather than `lower_case`), but that's personal preference. Consistency would be nice though.

i_crusade 15y ago

Other commenters are complaining about SQL written in the controller. I don't see this as problem in general, depending on project and workflow it can be valid. OOP nit-picks will see a problem there, but OOP users know how to fix it right? Back on topic: I'm grieving with ORM for some time now. The main problem is that people doesn't really think about how appropriate an ORM solution over any other solution is. They learn one ORM system and use it everywhere. Worse, they do everything the ORM way, writing abstract ORM queries that should have been straight SQL (for readability). And you know what? Those people (or projects) are fire-and-forget. They work on a project for few month and then they're gone. They don't have experience with projects that run several years and all those problems tied to it. I think ORM (or full-stack framework) prototyping is much faster than straight SQL - within it's limitations. But for long term projects it's likely toxic. So in my opinion, ORM is pretty good for prototyping or low maintenance projects, or just prototypes. Considering your past it's learning curve.