-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model Entity suggestion #549
Comments
The pattern I was following for that was, loosely, the Repository pattern. What you're asking for is pretty much against that and more toward an Active Record pattern, which is something that I wanted to stay away from on this. If I had to put it in terms of popular ORMs (which the Entity isn't the same at all, I realize), what you're looking for is something more like Laravel's Eloquent, where what I'm envisioning is more like Symfony's Doctrine. |
Why not just use Doctrine 2 instead of create a brand new ORM[-like]? |
We're not creating anything like an ORM. This is just a helper for making value objects out of a data row. We've always said that CI will not include an ORM, but if we did - it would because so many developers have asked us to :) |
Well, I hope I'm wrong and devs can avoid this helper when using a custom ORM, but am I? If I am, awesome, else it could be just like this, because most of the frameworks aren't. :/ Also I think that using a ORM like Propel3 with CI4 would be nice too. Is CI4 open to this kind of feature? |
The Entity isn't even required when using our database layer. However, if you're using a custom ORM, you'll be bypassing our Models and the rest of the database layer entirely. As far as Propel (or any of the others) you can use them just fine in your projects, as long as you realize the entire data layer is now based on their workflow and not ours. Composer is your friend there. :) As for replacing our data layer with a third-party ORM. That's not in the plans. |
I'd like to hear thoughts on passing the Model Entity object a reference of the calling Model object. This would need to be done in the BaseResult::getCustomResultObject() method and the reference from the Model class would need to make it's way down to the BaseResult object. This would allow the ability to call methods on the parent model object from within the context of the entity such as $user->save() instead of $userModel->save($user);
The text was updated successfully, but these errors were encountered: