views:

363

answers:

6

I have been a PHP developer for about 10 years now and until about a month ago I have never used a framework.

The framework I am now using due to an existing codebase is cakePHP 1.2

I can see certain benefits of the frameworks with the basic helpers like default layouts. I can deffinately seen the benefits of MVC keeping the logic sperate etc. But the query building just seems to be bloated. Is this expected?

Am I likely to be able to build better queries than the framework could build? I just feel I could get my apps running better without a framework.

What are your thoughts?

+1  A: 

Discounting the literal ton of php framework questions previously asked.

Depending on the query style you're using, yes queries can seem bloated. However this is true of anything other then running straight SQL.

There are some things the frameworks excel in. MVC patterns, quick plugins, libraries of helpful functions, etc. They don't normally excel in being super concise.

CakePHP is not where you should be looking for a less bloated framework. I have to highly recommend CodeIgniter. It's enough of a framework to where you can see the benefit, but at the same time very fast and nimble. I find the thought pattern much more logical in CI vs. Cake.

Josh K
+3  A: 

I'm not sure about Cakephp but in other frameworks I've worked with like codeigniter you're able to build your own queries too. Meaning you could use the premade query helpers or just write it yourself. There must be something similar for Cakephp.

For example, running a custom query on codeingiter is as easy as this:

$query = $this->db->query('YOUR QUERY HERE');

Consider taking a look at it here. They have one of the most friendly user guides I've seen with lots of example and pretty well written documentation. All the work I've done with it, if done without a framework, would've took me 10x times at least. Well, maybe not that much, but you get the point.

Also take a look at the database documentation, that includes queries, since that was what you seemed to be most interested in at The Database Class just so you see what I mean by friendly and well written documentation.

thisMayhem
Yes you can do this in CakePHP, as always remember to sanitize user input before pluggin it into raw SQL. `$this->MyModel->query($sql)`
deizel
@deizel I have no idea how Cakephp works, but I was sure it was possible. Thanks for sharing !
thisMayhem
much harder to code in traditional php in cake because it forces to you write according to their convention for their "magic" to work. CI is much more free
ggfan
http://debuggable.com/posts/cake-vs-zend-vs-symfony-vs-igniter:4942b243-85bc-404a-afc9-34aa4834cda3
deizel
True, but "their" convention becomes the same convention as all of the developers on your team, so even that has it's advantages when working on a project. ;)
deizel
A: 

I'm not sure about getting your apps to run "better" without a framework. "faster" perhaps, but not necessarily "better". Frameworks provide consistency that allows you to continue building and reusing on what is already there.

Public frameworks can seem bloated, especially with query building. It does seem silly to have to use 10-15 lines of code to build a query that could be written in 1 line. But it provides a level of abstraction so the same "query" will work on any database backend, without change. Of course, it's not often that you switch database backends.

Frameworks in general (public or your own) are a great thing and should be used. Your needs should determine which framework to use (if any). If you need speed, then that will leave out a lot of the public frameworks. CodeIgniter is one of the faster ones. But if you are not having performance problems, and don't foresee any, then CakePHP is a fine framework.

Brent Baisley
+5  A: 

Copying part of my answer from another question on the same topic:

What you need to look at is the tradeoff. Frameworks sacrifice a little performance for the ability to reduce development time significantly. What's more important to you, raw unadulterated performance or reasonably rapid development time? Facebook wouldn't use a RAD framework for their site, but that's because the performance to them is worth more than the added development time. Likewise a small company with a single developer is likely to benefit more from a framework than the reasonably small performance hit (I say small, because the impact on each page view is minimal. The effect "adds up" with higher traffic).

As for your question on query building, you are correct. You can build better queries than the framework can (because you know your exact schema and data set). However, the reason they have query builders (and ORM, etc) is so that you don't have to. It's not bad (as commonly thought) to write raw SQL with a framework. A framework is there to help take care of the common tasks and make it easy to fly through prototyping and rapid development. However if something's not working exactly right, or you notice a performance problem, or you feel that using a query builder is overkill for a particular query, just rewrite that query in SQL. I don't know of any frameworks that try to prevent you from writing SQL. They just try to make it so that you don't have to (which is ok, since it's typically one less thing to worry about)...

Writing query builders are one of the hardest tasks in programming (that I've come across at least). There's a fine line between being too verbose (and hence making it harder to write than raw SQL) and too weak (to the point that you constantly need to drop to raw SQL). What they are REALLY good for, is if you're building an application that you want to have "modifiable" queries (where one part of the code can modify the queries of another). That's VERY hard to do without an OO query builder.

But it all boils down to this. Do what you feel comfortable with. Don't feel obligated to use a Framework's method just because it's there. If you feel more comfortable writing raw SQL, then write raw SQL. But realize that you MAY be losing some of the benefits of the framework if you do (Cross DB compatibility). If you're ok with that, then go for it. Remember, Frameworks are there to make your life easier...

ircmaxell
+1 for on-topic answer, and for mentioning portability as one of the advantages of ORM.
deizel
I would stress that last part a bit more. Query builders abstract the actual SQL away from the intend, which makes the app incredibly portable. This can be a real plus if you need to switch database backends later as the application matures (say because MySQL doesn't cut it anymore for the size your app has grown to). Once the platform your app runs on is shaken out, you can hardcode queries if performance demands it.
deceze
+1  A: 

All frameworks necessarily introduce a degree of bloat. You don't get something for nothing. Most of the time it's a tradeoff that's worthwhile and as you become accustomed to the framework - in your case CakePHP - you'll come to appreciate the consistency and repeatability it brings to your work, not to mention the ease of maintenance and drop-in reusablitity of code chunks.

You may well be able to write more efficient SQL and CakePHP provides functionality to allow you to do this, you can find it all in the book. Any framework ought to allow you to drop into the native language at any time and CakePHP certainly won't hinder you in this respect, but I'm sure you'll soon find that the CakePHP wrappers for everyday SQL make life a lot more pleasant.

Regarding frameworks in general, I spent some time comparing frameworks before realising that without using each one for a couple of years I couldn't possibly make an informed choice - and most of the this-one-is-better-than-that-one is based on people's experience with one framework and maybe a few days of unhappy experience with another. I chose CakePHP because I realised I just had to make a decision and stick with it. I don't regret my choice and I don't have time for the pro-con arguments. I had work to do and I had to get on with it. I'm comfortable with my choice and couldn't give a monkey's about the others. The bottom line differences are marginal.

It's how well you know the framework not the framework you know.

Leo
+1 Nicely worded.
deizel