Laravel ORM (Eloquent) and the real world

[sKunKbad]

So, it is here in this forum that I first found help with PHP back in 2006 when I started learning PHP. I worked on my own websites, and slowly learned more and more. In 2009 started using Kohana, and then switched to CodeIgniter because it felt easier and felt like it was faster. Now it seems like as a PHP dev I'm just expected to use Laravel. Being a CodeIgniter dev is like having leprosy.

 

Laravel seems easy enough, and I've enjoyed learning the basics. I just feel like the ORM, which is a big part of its magic, is not for me. I like writing SQL, and I'm no expert but Laravel ORM (which is the only ORM I've attempted to learn) just isn't something I enjoy. I do love the way pagination is tied in, but that's about it.

 

I now mostly work for one person, and his website is the largest I've ever worked on. I've been working with him for 4 years or so, and the database has about 170 tables. I'm having a hard time believing that somebody would use Laravel ORM on something with that many tables, having to set up all the models, and deal with the bizarre relationships, migrations, etc.

 

I know at least the mods and gurus here are way more knowledgeable than me in most areas of dev, and I'm wondering if any of you use Laravel ORM or any ORM for that matter. Do you use Laravel without the ORM?

 

At one point I was playing around with learning Ruby on Rails, and I can see the similarities, but then remember hearing somebody say that real world websites don't really work like that. What I mean is that they don't fit the cookie cutter examples that are presented in tutorials and training videos. So, I suppose the same could be true with Laravel, yes? If that is true, is the ORM primarily just for basic stuff?

[benanamen]

I have never used a third-party framework and in all my years I've never found a "need" to use one. I do have to say that in all the projects I have worked on, I have been the only programmer and have built everything from the ground up so that could make a difference for some. I created a dynamic crud generator that can create an entire back end at the push of a button in a matter of seconds regardless of the amount of tables. Using the party model DB schema I can scale to Infinity on large projects with no problem. I would say just use the right tool for the right job. I am interested to see the feedback you get on this.

Edited June 5, 2016 by benanamen

[kicken]

I've been using Symfony and Doctrine ORM for a while now, and over all I've found the ORM stuff to be alright. It certainly did take a while to get used to after having used DIY querying for years though.

 

The ORM doesn't completely remove the need to do your own SQL queries, but it does help with removing the need to do some of the more basic DB work. It helps you to keep your data management in PHP rather than having to mess with a bunch of queries for simple things. For example, adding a new record is as simple as doing something like:

$u = new User('kicken');
$u->setRegisteredOn(new DateTime())->setStatus('active');
$orm->persist($u);
$orm->flush();

Much nicer than having to deal with generating the appropriate SQL, do the parameter binding, etc. Fetching / Updating / Deleting data is similarly simplified.

 

Using an ORM isn't a "never write SQL again" mode though. While it helps remove a lot of the simple/boilerplate type stuff, for more advanced querying you'll likely still be writing your own queries and handling results manually. For example when building reporting tools or advanced searching/filtering of data.

 

I've found that in a lot of my projects at least, most of the time I'm dealing with data in ways where the ORM features work just fine and I can avoid having to deal with custom SQL. Typically I'm working directly with specific entities and can load them by their ID or by a simple search (eg, by name). Rarely do I find that I have to create custom queries for data, usually the custom queries are only needed some specific instances (which tend to overlap) such as:

• Generating complex reports
• Complex filtering of data
• Dealing with massive amounts of data

In those situations there can often be a more optimized way to query for the data than what the ORM system would do. For example if your accessing a bunch of records for a report, the ORM may run out of memory by trying to load the entire result set and all the data for each record. By querying yourself you can easily limit the results to only the columns you need and process results as they come.

 

 

Of course I can't say much as to what the rest of the web is doing with there systems, but I would imagine that most applications have some kind of ORM-like setup that lets them worry less about the SQL and focus more on the data. That is mostly the point of ORM systems, focus on the data and your code and less on how to talk to the database about the data.

[sKunKbad]

I was waiting to see if anyone else replied. What you guys said makes sense. Thanks for your input.

[gizmola]

My experience mirrors Kicken. I had worked on a large symfony1 app, as well as a big ZF1 project before symfony2 and ZF2 became things.

I used various database libraries and ORM's on those projects, Propel for the Symfony1 project as I recall.

 

At that time Doctrine1 existed, and then the symfony2 project came out with a much higher binding to Doctrine2, in borrowing some of the things that the Doctrine2 people had created for annotation and event handling.

 

Whenever you are dealing with an ORM it takes a bit of time to change your thinking, because ORM's are concerned with "objects" and not tables. Often that is advantageous (see Kicken's example Doctrine2 code) and once you start to use all that baked in goodness you really come to appreciate what it can do for you.

 

With that said, it is not always the most efficient code, nor memory friendly, and people that just want to write raw sql have a hard time dealing with it. To have it work properly you have to design your tables and relations the right way, and it helps save time if you use their conventions, or you have to do extra configuration.

 

Instead of thinking about the relationships between tables, you have to think about the relationships between objects, and the ORM will often have default behavior that tries to do all sorts of things that make it simple for you to deal with data, but sometimes you realize that it's doing lots of queries you don't want it to do.

 

 

Ok, so much of that has to do with doctrine2 and symfony2, which I used on a project to build a pretty complicated (not to mention supposedly scalable) social network application that included social graphs and lots of the the stuff you expect in those types of apps. We also threw in MongoDB and built a hybrid app where some of the data was in a relational store, and some data was in mongo.

Doctrine2 allows you to use the same basic model and repository classes which was very helpful in stitching everything together.

 

I also have worked on several Laravel projects, and Eloquent has similar capabilities, but is far less ambitious.

 

To understand Eloquent, the main thing you need to know is that the goal of Eloquent is to implement ActiveRecord. ActiveRecord is a design pattern proposed by Martin Fowler where there's more or less a one-to-one relationship between a class and a table, and each object represents a single row in a table. You then have methods like $obj->save(); My take on Eloquent is that it does the bare minimum to be an Active Record implementation, and there's nothing wrong with that approach. Like most ORM's it has a querybuilder component that often strikes people who are used to hand crafting their SQL as being an annoyance and not worth the trouble.

 

However, once your application begins to get more complex and you have components that implement pagination and integrate with caching libraries, and in general becomes more sophisticated, you start to see the value of having an ORM that often supports and integrates with the component libraries.