The average developer is happy working with single-server setups using relational databases and issuing queries written as strings. There is little to no concept of continuous learning in the PHP world.And here again, an OOP-based mindset doesn’t exist, so a framework, a service container, a design pattern, an ORM. Discarding the very small percentage of PHP exposed to frameworks such as Yii, CakePHP, etc., the remaining are used to working in core PHP or in an environment such as WordPress.As a result, when learning Laravel, the idea of an ORM is 100% new to PHP developers. And though we have a new CodeIgniter today, the habits have carried over. In the older CodeIgniter community (if there was one), the “best practice” was to directly stick SQL queries where needed. Prior to Laravel, the exposure to a framework for most PHP developers has been CodeIgniter (it’s still alive, by the way, even if it’s become more Laravel/CakePHP-like).That’s the real underlying issue, and in my opinion, there are several factors contributing to this (harsh, unpopular opinion alert!): What actually happens is that PHP developers learning Laravel find Eloquent hard. Compared to these, learning and using an ORM.
#Eloquent orm code
Live schema migrations are hard writing a new templating engine is hard contributing code to the core of Laravel is hard. At least when seen from the perspective of the definition of “hard”. If you ask me, I’ll say that Eloquent model relationships aren’t hard at all. I think it’s an important point and is worth some reflection. Sadly, I come across far too many Laravel developers who don’t understand models properly.Įven today, when there’s an explosion of courses, articles, and videos on Laravel, the overall understanding is poor. Why are Eloquent model relationships hard? In this article, I intend to cover all of it, starting from the very basics and then covering all possible use cases that you will encounter in real projects. Then one day I came across some neat Collections tricks that make this work more pleasant. I was finally able to model projects properly and use the models comfortably. (By the way, I’ve been attacked for attacking the official documentation before, so if you’re having similar ideas, here’s my standard answer: go check out the Django documentation and then talk to me.)Įventually, bit by bit, it did come together and made sense. Or even if I did come across some useful article/resource, the explanation was so bad or so badly missing that it was just no use.
Examples modeling authors and blog posts are a joke because real projects are far more complex sadly, the official docs use the very same (or similar) examples. Or at least, the relationships between models (because Eloquent is too large to learn completely).
I must have done this 5-6 times before it started making sense to me (of course, the documentation doesn’t help).īut what still didn’t make sense was Eloquent. One reason was that I was not using it at work and was exploring it out of curiosity so, I’d make an attempt, get to a point, get confused, give up, and eventually forget everything. But I’ll be honest - I had an extremely hard time learning Laravel, if only because it was my first full-stack framework. Sitting on the other side of their programming article, it’s easy for the writer to feign or blow up the aura of expertise/prestige the platform provides. If they give you a hard time or you’re not able to find a simple, friendly, and complete guide, start here! Models and their relationships are the heart of Laravel Eloquent.
0 kommentar(er)
