On the CodeWall.co.uk site there's a new tutorial showing you how to use Eloquent outside of Laravel applications thanks to its "capsule" functionality. Eloquent is an ORM layer that's a part of the Laravel framework and makes it easier to work with records and sets of data from your database.

OWASP (Open Web Application Security Project) is a project that notes down the current threats to a web application. And I have been researching on their site and I have found this similarity in their 2010, 2013 and 2017 report that, SQL Injection or any other type of Injection is number 1 on this list, every time.

And that’s a part to worry.

This can cause you to get out of business, so this is pretty serious and your organisation should take care of the this issues and prevent yourself from it.

The tutorial starts with a brief introduction of what SQL injection is including some example SQL to show how the injection happens. It then covers how to prevent this issue with base PHP code (no framework or package) using prepared statements and bound parameters. Eloquent takes care of this for you and provides a lot of other handy features. The article goes on to show:

• how to install the Eloquent packages with Composer
• the code to create the "capsule" that's used as a bridge into the Eloquent code
• the creation of migrations for two tables: users and posts
• how to make models for these two tables

The post wraps up with a look at using these models to create a new user and post record using the ORM interface rather than manual SQL statements.

Tomas Vortuba has a new post to his site sharing a few reasons why he thinks that Doctrine isn't dead and is still "alive and kicking" with things still changing in the project.

Almost 1,5 year ago I wrote Why is Doctrine Dying. I didn't use dead, because it's is just state of time being. Open-source projects - like people - tend to find themselves on the top, being stuck or struggling with the right path from time to time. It's a completely normal process of evolution.

I don't know if that post helped it, but since then many things changed for better in Doctrine project. Saying that this post deprecates my old view and celebrate changes.

May this be an inspiration for open-source projects that find themselves stuck and the maintainers that find themselves unhappy.

His list includes reasons like:

• Bump PHP 7.1 Without Waiting for Major Release
• Cut the Weight to Save Yourself
• From Talks and Post Evangelization to Code Improvements
• New Release as a Baseline

For each point, he provides a little clarification and background from commits to the code and statistics about the community around the project.

Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

On the Laravel News site there's a new post sharing twenty Eloquent tips for the Laravel users out there.

Eloquent ORM seems like a simple mechanism, but under the hood, there’s a lot of semi-hidden functions and less-known ways to achieve more with it. In this article, I will show you a few tricks.

Among the tips and "hidden features" mentioned are tips about:

• Increments and Decrements
• Model boot() method
• Model properties: timestamps, appends etc.
• Order by relationship
• Order by Mutator
• Raw query methods
• Create additional things when creating a model

...and many more. There's code examples for each of them showing them in use too.

In a new post on his Medium.com site Romans Malinovskis has posted an objective comparison of ORM/DBAL libraries based on his own list. It includes several different libraries from all around the community including Doctrine, Eloquent, Cake ORM and Agile Data.

For many of us, developers, pattern of accessing external data (SQL) is a thing of preference. We get used to different syntaxes and subjectively endorse it. By looking past the individual preferences, I wanted to create a “comparison criteria” that would help PHP community to objectively evaluate data persistence frameworks based on features. As I looked around I haven’t found anything, so I started to work on my own list:

https://socialcompare.com/en/comparison/php-data-access-libraries-orm-activerecord-persistence. I welcome my readers to help me populate and use the table. In this article I explain various features which I’ve used as comparison criteria.

The (lengthy) post is divided up into sections for each of the criteria including:

• Sections and Scope
• Support of Persistence Engines
• Criteria, Scope, Condition
• Query Building
• Single-record operations
• Relations and References

...just to name a few. Each section comes with an explanation of what it is in a library-agnostic way and code examples where relevant. Be sure to check out both the table and the rest of the post for the full details.

Geoff Wozniak has written up a post on the "Curried lambda" site sharing his opinion on ORMs (object relational mappers) for working with databases and how, after using them in his own development work, that they're a good side benefit but shouldn't replace knowing SQL.

I've come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.

[...] Neward, in his well known essay, lays out many cogent reasons why ORMs turn into quagmires. In my experience, I've had to deal directly with a fair number of them: entity identity issues, dual-schema problem, data retrieval mechanism concern, and the partial-object problem. I want to talk briefly about my experiences with these issues and add one of my own.

He breaks the rest of the article up into several sections, for each sharing some of his own experiences with the feature and how it could be resolved using other query methods:

• Partial objects, attribute creep, and foreign keys
• Data retrieval
• Dual schema dangers
• Identities
• Transactions

He ends the post with a look forward, thinking about where he'll end up, mentioning stored procedures, queries as APIs and how "easy" isn't always best when it comes to ORMs.

Romans Malinovskis has a post on his Medium.com site sharing what he calls a "pragmatic approach to reinventing ORM" with his thoughts about a different approach to this commonly used database interface.

It’s been over a year, since I posted my first highly debated post on Reddit: Reinventing the faulty ORM concept. Gathered information helped me design and implement an alternative pattern to ORM with many important advantages and that has reinforced my belief that ORM is faulty.

He's broken the article up into a few sections with details and thoughts for each along the way:

• Why ORM is important?
• Why ORM is broken?
• How Agile Data differ in approach?
• How Agile Data qualify production/enterprise use?
• Notes on architectural decisions in Agile Data (OOP vs Decoupling)

That final section focuses mostly on the decoupling aspect and the Agile Data library (a Data Mapper) that can be used and solves some of the common ORM problems he mentioned in the earlier sections.

The SitePoint PHP blog has posted a new tutorial focusing on the Atlas ORM, a recent addition to the wide range of database ORMs in the PHP ecosystem, focusing on being a mapping of your persistence model.

By definition, a Data Mapper moves data between objects and a database and isolates them from one another. With a Data Mapper, the in memory objects don’t even need to know that a database exists. It does not need to know the SQL interface or database schema; it doesn’t even need the domain layer to know it exists!

This might lead us to thinking that, in Atlas, the persistence layer is totally disconnected from the database, but that is not quite what happens. [...] An Atlas Record is passive; not an active record. Unlike most ORMs, its objects represent the persistence model, not the domain model. Think of it as representing how the data is stored and not as real world representations.

The tutorial goes on to talk about some of the background behind the package being developed and some of its core principles. They then walk you through the installation of the package, doing a bit of related database setup and the code to perform some basic CRUD (create, read, update, delete) operations on the tables. This is followed by a few more practical examples and a few caveats for the library's use.

On the Master Zend Framework site there's a new tutorial posted showing you how to integrate Laravel's Eloquent database library with Zend Expressive to replace the usual options of Doctrine or ZendDb.

When working with Zend Expressive, if you were to choose a database layer for your application, I guess that the first two names to come to mind would be either ZendDb or Doctrine. But what about Laravel’s ORM: Eloquent? That’s right, Eloquent!

I’ve been getting to know Laravel a bit better recently, primarily for the comparison I wrote about it and Zend Expressive not that long ago. The tutorial was exceptionally well received. So I thought I’d dig a bit further, and see if I could use Eloquent instead of my standard ZendDb. It turns out, with a bit of work, you can do it!

In today’s tutorial, I’m going to step you through how to make it available, using a project based off of the Zend Expressive Skeleton Installer.

He starts by installing the Eloquent package and setting it up with a simple configuration (using a Homestead environment). With that configuration set up, he shows how to make the Eloquent connection available to the rest of the application. Once the connection is set up he shows how to create a first model - Capital - and using it to create a new record. He also includes examples of retrieving all records and mentions three things that seem missing from this Eloquent install: the "artisan" command, migrations and database seeing functionality.

The Laravel Podcast, hosted by Matt Stauffer (with guest hosts Taylor Otwell and Jeffrey Way) has posted its latest episode - Episode #42: ActiveRecord & The School Of Zonda:

In this episode, the crew is joined by Adam Wathan to discuss ActiveRecord and the Eloquent ORM.

Lots of talk around ActiveRecord vs DataMapper and discussing the positives and negatives to each.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the show, be sure to subscribe to their feed or follow them on Twitter of the latest show updates.