Entity models?

The CI_Model is collection-centric, mapping more so to a table of X than a specific X.
Does it make sense to provide better entity model support?

This could take the form of a Customers model being "backed" by a Customer model, for instance.
The DB query methods for Customers would return instances of Customer, rather than stdClass.

--------------------------------
Disclaimer: Putting forward an idea without implying any endorsement of it.

James Parry
Project Lead

I should have voted 'Maybe' on this one.

I tend to write my own getOne and all functions and they return arrays.

Same as albert.freeman. I hate ORM, so also a maybe from me.

Don't try to make own ORM, just make it easy to integrate some 3rd party. Doctrine/Propel/Eloquent...

Maybe here.
While it sounds good in theory adding a "ORM" of sorts if done incorrectly may start to enforce a certain way of data modeling.

We also need to remember, models don't always imply a database/table relationship.
A model could represent a folder of files, config file, NoSQL DB, CSV file, sFTP connection, RSS feed, etc...

DMyers

https://github.com/ProjectOrangeBox / https://github.com/dmyers2004

I think ORM is too huge work for just adding it at CI..
There is so many things that have to be handled .. I don't think it have point..

Perhaps instead we can think of creating some CI additional extension that integrates a ready ORM solution as Doctrine..
Not inside CI default framework installation but additional package which will give developers the option to use the power of ORM within their projects with FULL CI compatibility..

Best VPS Hosting : Digital Ocean

I asked James about this, thinking it was close to an ORM, also, and we are wrong here's what he was thinking:

Currently: $this->load->model('model','var_to_use');
Suggested: $this->load->model('model','var_to_use','class_to_use');

CI_Model or DB query would use the supplied classname instead of std_class when building result sets.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

What I was suggesting has nothing to do with ORM. It is just a way of having the existing model be able to use something other than stdClass. The "entity model" would represent one record in the returned result set, and could be whatever you want it to be. Properties would be injected into such an object the same way they are in a stdClass object in a result set, but we would then have a way to do something entity-specific with such objects.

James Parry
Project Lead

I think the main problem is that, in the last few years, almost anything related to the Model in PHP MVC frameworks has been slapped with the label ORM, even when the main focus of the code in question has little to do with implementing any object-relational mapping patterns.

Further, CI is built with such a focus around the Controller that many of the models commonly used in CI do little to encapsulate the underlying data source. This, combined with the relatively thin nature of CI's DB class, tends to result in the view of CI's model as "collection-centric", though there's nothing in the model itself that makes it so.

Given the relative simplicity of CI's model, it might make more sense to create a class which represents a collection of models. In this way, the model itself remains untouched, but someone who wants to use the higher-level separation between the collection and the model would be inclined to structure the model to represent an individual record returned by the collection. Then the collection itself could be loaded by the controller and would return an instance of the model instead of a stdClass or an array.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

I will vote yes. I have been seen myself many times writting these entities to work with models in CI. Furthermore, I don't think that ORM would be a bad practice.