FuelPHP Forums

JasonJudge

Some of my recent questions have resulted in exposing my confusion between the ORM and CRUD models, which appear to be different - and incompartible - things within FuelPHP. In trying to find out more about the difference between the two, this page came up on my first search: http://docs.fuelphp.com/packages/orm/crud.html It talks about ORM and CRUD interchangeably, as though they were one and the same thing. However, both use different base models and their methods (of the same name) take different parameters and return different data types. The ORM model supports relationships and chaining, while the CRUD model does not. CRUD is in the core, but ORM is a module (though included with the core in downloadable releases). So - where are these two object models going? Will they merge? Is one a left-over of some past development, perhaps to be deprecated? Are they going to diverge and settle down into two different roles? Is it likely that an application will actually need both? Just curious as to which I should be focusing on. -- Jason

Dregond Rahl

Model CRUD is a very simple CRUD system, its not ment for relationships like one-to-many, many-to-many and such. Ofcoruse you can use joins with closures to handle this but its not inbuilt for relationships. Its useful for simple projects without too many complicated relationships. Performance is better with this, since its not for relationships. ORM is designed to handle multiple relationships, and the CRUD operations of those objects. Its very advanced at handling interactions with the database. Neither are depreciated as of 1.x branch. However in 2.0 ORM made be dropped for allowing users to use Doctorine or any other 3rd party ORM. Model CRUD will likely stay as its pretty simple and doesnt require any 3rdparty packages.

Harro

Slight nuance. ORM will not be dropped, but it will no longer be part of the "core" set of packages. As we are going to move to composer packages for 2.0, it will be quite easy to install any ORM that is PSR-0 compatible and for which a composer package exists. Currently, Packagist lists composer packages for Doctrine and Propel.

JasonJudge

That all sounds great. For a production system now, I will stick to ORM, but keep an eye on the codebase to see how that develops. The PSR-0 stuff is new to me, but it seems straight-forward and a good way to go after a bit of reading up. There is more to learn with this Packagist and composer stuff - presumably the means to deliver and manage the packages. How much of this could be added to FuelPHP 1.x just to see how it would all work? I am personally not a big fan of introducing too many third party service dependencies into products, so I'm hoping there will always be a fall-back allowing these packages and libraries to be installed by hand. It's great for projects that are here today and gone tomorrow, but some projects can last many years and can sometimes outlive the projects that the components are delivered from. I've seen that happen too many times over the years. That's just a personal observation, and may not apply in this case, bit something to consider. -- Jason

younes0

Does the Model_Crud prevent SQL injection ???

JasonJudge

younes0 wrote on Wednesday 29th of August 2012:

Does the Model_Crud prevent SQL injection ???

If it didn't, I doubt it would have even been considered for Fuel. Using the model, you don't mess around with SQL at all. You just push data around, so SQL injection is not even a question on the table.

Harro

PSR-0 is something the PHP community is adopting as a standard (including PHP themselfs), and although I hate the CamelCase names, it's something we have to live with. I personally don't see why you wouldn't use third party solutions. It's better to use something external that is well build, maintained, and has an active development team, then use something that isn't getting the attention it deserves. I know first hand (through my Datamapper ORM for CI) how difficult it is to create and maintain an ORM, so when it's time for a developer to determine on what to spend his free time, reinventing wheels should not be high on the agenda. That time can be better spend on the framework itself.

JasonJudge

WanWizard wrote on Sunday 22nd of April 2012:

I personally don't see why you wouldn't use third party solutions...

Note: services, not solutions. I'm never one for reinventing the wheel, and will user (and hopefully give back to) any project that has a solution that fits.FuelPHP is a good example ;-)

For me, it is the services that carry a little more risk, if that service is hard-coded into the core of a product. I can see how it is necessary to handle dependencies, having all the dependent packages in one place. However, it does mean you are relying on other people to keep *those* products updated, and rely on that service to stay up (in your timezone) and rely on their ability to keep funding their project etc. Maybe I am just old school, and like to know where my code is coming from, rather than just being one in a big chain of middle-men. But - looking forward to seeing how it is going. I don't want to go off at a tangent discussing how interdependent the whole Internet/WWW is becoming, and at a time when governments and corporations are doing their best to lock it down and regain more control over who gets access to what. -- Jason

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion