CI v Yii v Procedural v Whatever Else

[eluser]LovinItAll[/eluser]
Hi,

Okay, I expect to get slammed a little, but I'm a big boy and can take it.

I've been writing procedural PHP for years, and I have a long (non-OO) programming background. Without discussing the merits (or demerits) of my intentional avoidance of OOP in general (principally due to large libraries I've developed and the relatively small nature of the projects I take on, coupled with the fact that there are never more than two developers working on the same project at the same time), I find myself in a dillema:

- I have a VERY large project that I must begin working on immediately (as in I need to start writing code today and assigning portions of the project to other developers now)
- There will be a minimum of 4 developers working on the project simulataneously, and 6-8 is not out of the question. Unlike previous projects, there will be a design team to content with, as well.

Even though I have my own version of MVC implemeted using my prehistoric procedural methods, it is not documented in a way that can be easily understood by someone totally new to 'my world', hence my quest to find something that:

- Has a relatively flat learning curve
- That is well documented and has a decent community of users to scavenge help when I need it (please consider 'scavenge' a term of endearment
- Will perorm well against a large user base that is constantly hammering away via HTTP at my DB's (I have no problem throwing hardware horspower to make up for any inherent performance issues if said HP will overcome the performance issues themselves)

Which brings me to my long-winded question:

- I've looked at Yii and the performance benefits it touts due to it's native support of PHP5 and no backward compatibility issues. I find it oh-so-non-intuitive.
- I've looked at CI and grasp the OO model and it's MVC structure almost immediately

Am I really giving up serious performance using CI v GOOD procedural techniques? If it's a given (and I'm not saying it is) that Yii simply hauls ass, is it really worth me going bald trying to figure it out?

I've looked at benchmarks various users have published, and most point to GOOD procedural MVC paradigms outperforming OO frameworks by a large margin. Someone convince me it ain't so!

I've been going back and forth over these issues for days, and I can't waste anymore time. Had I just handed out assignments last week and said, "Go procedural - here are my libraries, figure them out", I'd be well into the project by now (I have a great prototype/wireframe).

Your comments would be well appreciated. Dunk me for not OO'ing it a long time ago if you want - it really doesn't matter. I am where I am, if that makes sense.

(Man, I hope some of you guys are up at 6 A.M.)

Thanks.....

[eluser]n0xie[/eluser]
I don't know exactly what you're asking.

On the one hand you try to compare procedural code vs OO code. You keep hammering on 'GOOD' procedural code. Does this imply you write 'BAD' OO code? Define 'GOOD' procedural. Does it mean it works? Or does it mean it's easy to maintain? Or does it mean it is very readable? Or does it mean it's easy to change/adjust/extend/override?

You also worry about performance. In my experience, the code is rarely the bottleneck, so I don't know exactly what it is your expect to get out of this question. Yes, OO has overhead and thus is slower. The benefit is that your code follows SOLID principles (if you do it correctly), is much more managable and readable. Because of this it's almost always easier to scale OO code, since procedural code is usually not encapsulated and thus very difficult to take pieces out, but again this is very much a question of how good a programmer you and your company are. For example, Rasmus Lerdorf prefers to write procedural code. I dare say he knows a thing or two about programming...

So bottom line, if you're comfortable writing procedural code, keep doing that.
If you see benefits in writing SOLID code, learn OOP, but learn it well.
If you worry about performance, don't. Scaling is something you worry about later.
If you don't know which framework to chose (YII or CI) I would say, try them both out. See what fits your needs the most, or which you find the most intuitive. Remember a framework should help you, not get in your way, so if you constantly have to lookup how a framework 'works' it kinda defeats the purpose.

In the end whatever gets the job done is probably the best choice.

[eluser]jedd[/eluser]
Hi LovinItAll and welcome to the CI forums.

I can't give you any fantastic insight into your current problem - not a position I've been in, and just how badly documented your personal MVC framework is .. can only be speculated at

What I can suggest is that if you're not a huge fan of OO, then CI won't force it down your throat. For the most part your code can be kept looking a lot like a 'procedural' MVC framework - so if that's your only concern, then you can let that one go. Of course, some would argue that using the OO approaches and aspects of CI will make for a better system - that's a much bigger, and quite different argument.

Oh, and it's midday if you're in a sensible timezone.

[eluser]LovinItAll[/eluser]
[quote author="n0xie" date="1253809468"]I don't know exactly what you're asking.

On the one hand you try to compare procedural code vs OO code. You keep hammering on 'GOOD' procedural code. Does this imply you write 'BAD' OO code? Define 'GOOD' procedural. Does it mean it works? Or does it mean it's easy to maintain? Or does it mean it is very readable? Or does it mean it's easy to change/adjust/extend/override?

If you see benefits in writing SOLID code, learn OOP, but learn it well.
If you worry about performance, don't. Scaling is something you worry about later.
....Remember a framework should help you, not get in your way, so if you constantly have to lookup how a framework 'works' it kinda defeats the purpose.

In the end whatever gets the job done is probably the best choice.[/quote]

Point well taken, and sorry for my lack of clarity regarding solid procedural techniques - the assumption was that the CI (or other) framework employed best practices and therefore was, by definition, 'good'. What I was implying was, for example, my procedural implemetation of CRUD, including validation/sanitization that may read:

function myCRUD($tableName, $priKey, $action, $foreign = NULL)

handles virtually all of my interaction with the DB, as opposed to implementations that I've seen that call 4 functions to do the same thing, with the point being that it's easy to read/implement and there is no maintenance with regard to this specific example of a redundant action. Of course, I have many examples like these.

I think where I started wigging a little was with the notion that I'm going to have to hire developers who obviously will have no knowledge of my wicked ways, but may have a solid understanding of a popular framework. Does that make it a little clearer? I think, "In the end whatever gets the job done is probably the best choice" is the best answer, and I may be making much ado about nothing.

Thanks

[eluser]wiredesignz[/eluser]
Codeigniter is a good choice for a framework to learn MVC, OOP and any of the other cliché design patterns. It is also widely recognized and has a pretty good reputation.

Yii is slightly more advanced and would be a lot easier to use after working with CI for a while.

Good luck with your new project.

[eluser]BrianDHall[/eluser]
Here's a good performance rundown of everything but Yii - and unfortuantely I can find no good real performance test of Yii, so beats the hell out of me. http://amiworks.co.in/talk/codeigniter-i...framework/

Now this shows that CI, even being the fastest of all the main frameworks (not testing Yii), is still slower than pure PHP. However, this is not a good appraisal of your solution vs CI as obviously you have quite a bit of neet functions and such going on.

Now, you mentioned using some extra hardware. There is no reason you can't use a clustered or cloud solution with CI - CI adapts extremely easy to even the largest of such scaling. If you need 20 load balanced front-end servers and 10 DB servers (segmented into two sets of 5, 4 being load-balanced mirrors of each master DB server, and inserts/updates only done against the main DB server, with an attempt at seperating intensive tasks between the two master servers - which is near-trivially doable in a 'warm' environment so you manually load-balance). Throw in some more stripped-down content servers for your static files, minimized (for CSS and java) and gzip encoded with heavy caching and a well-configured firewall and jesus christ on a cracker, you have one hell of a robust solution.

I sympathize with you on going from Procedural to CI, because that's exactly what I did. I was faced with having a bonus if I could finish a 2-page list that could not reasonably done with the existing solution, so I needed to rewrite it entirely. I did this with functional PHP from scratch on time, yay!

...and I had spaghetti code I didn't really like, so I tried to port it to CI. Only took 2-3 days from never having used a framework before.

If I were you I'd go with CI and Git source control from the beginning, clearly lay out the tasks to each developer, and go for it.

CI has a 'lets get started' learning curve measured best in hours for experienced programmers - not days or weeks. Meanwhile I tried symphony and couldn't get through the first three chapters of the damn tutorial that was supposed to be so easy to follow. Damned command line.

If you need something now without previous experience in MVC or Frameworks, I think it is logically impossible for you to pick any better framework. Its practically what CI is designed for. Rasmus Lerdorf notes it is his favorite framework in his keynote speach on simplicity: http://szeged2008.drupalcon.org/program/...imple-hard

CI will permit you to use your existing functions if you want, or even wrap them for other developer simplicity if need be. It has easyish to learn ORM from Datamapper Overzealous Extention (I highly recomend - I didn't use for my first project but am for my second, and wish I'd used it for the first - am considering a refactoring to use it). Its easy to refactor as you go, so you can clean up any messes you make without too much difficulty, so don't freak about doing things the 'wrong' way to start with.

I recommend you invest in the few days it takes to get everyone setup with netbeans with XDebug - soooo important for you, you will hate yourself if you don't get setup with a debugger, but what IDE you choose is up to you I just like Netbeans now a lot - and source control, and get going. Don't worry about your existing libraries, use CI and ORM if you feel comfortable as there is FANTASTIC documentation and tutorials they can use to learn as they go.

If you run into something that makes you go "Well hell, Zend has a great library for this"...use it, CI allows it. If you find one of your own functions you really want, stick it in a library or helper and go for it! "Helper" functions are purely...well, functional, so CI will happily accept yours.

Yii is much smaller, less documented, more 'magic' (harder to understand), more bleeding-edge - I didn't even consider it for my project, so I can't recommend it. CI I can honestly say I think you will really, really be happy with.

[eluser]BrianDHall[/eluser]
Oh, about OOP vs functional performance - the hard truth is OOP will always be slower than functional, for the same reason that Assembler code is still the faster solution to programming ever, bar none.

But hey, PHP is slower than using javabean servers and waaaaay slower than writing your stuff in C, so you have already accepted the tradeoff of development ease vs pure processor power.

The answer is hardware, because CI is very very very quick to load itself and produces only the tiniest delay vs a pure php echo script.

I'm guessing your PHP developers would make at least $2500 a month USD? I would rather have 7 developers and amazingly powerful hardware (which $2500 a month, plus government expenses of taxes etc which I believe usually add up to 50% more cost than the salary, would easily buy you) than 8 developers coding to try to minimize hardware expense.

I believe $500 a month will buy you a load-balanced, firewalled, 2 front-end, 1 dedicated DB, clustered setup at a professional hosting company. $2000-3000 a month would buy you so much damn raw power that the difference in OOP and functional would, I predict, seem like a damn good bargain.

[eluser]BrianDHall[/eluser]
Wow, just looking into Rasmus Lerdorf slides a bit more produces some really interesting insights. http://talks.php.net/show/drupal08/30

A static html page on his system pulls 600ish requests per second. Opcode cached PHP hello world echo file still gets 600ish requests per second - no cost due to opcode caching.

For frameworks CI pulls 300 for hello world. Half the speed - but even the next fastest framework (Zend) is less than half CI performance.

This is not saying that Zend is half the speed of CI, nor that CI is half the speed of pure PHP - but it shows that CI is just about as light as it gets. It helps you with some basic things, and gets out of your way.

Rasmus pure PHP application he built for his presentation got about 60 requests per second on his systm. The point of his whole presentation is that it is what YOU write that will matter, not PHP, and in the case of CI not even the framework. Now if you use Cake or Prado (ick), etc, you will be taking quite a bit of overhead. Just running the frameworks there take up more processor power than some full applications.

So this is just some more 'code away' advice.

[eluser]LovinItAll[/eluser]
I wanted to thank everyone for their points of view. It's really not like me to get stuck in 'Analysis Paralysis', but I was there and I knew it.

I think having someone say something as simple as, "The point of his whole presentation is that it is what YOU write that will matter, not PHP, and in the case of CI not even the framework." was enough to move me to a decision, which led to action, which led to being productive. Again, the gravity of my project and the number of people involved had me second-guessing myself, and I just needed to get the hell over it. Many thanks to those that helped me do just that.

CodeIgnitor looks very promising, and I look forward to continuing to use it. Being new to OO (and for whatever reason avoiding it all these years), I was pleased to discover that my "fears" were so unfounded - I began making extensions to classes almost immediately using unique code I've written over the years that do some specific things that aren't in CI. I had this notion that my previous work would be unusable - I hate when my own ignorance rears it's ugly head. Still a little disappointed in myself that Yii seemed so difficult, but it's a mere afterthought now.

Thank you again, and best of luck on your own projects.

[eluser]n0xie[/eluser]
[quote author="LovinItAll" date="1253886975"]
I began making extensions to classes almost immediately using unique code I've written over the years that do some specific things that aren't in CI. I had this notion that my previous work would be unusable
[/quote]
Don't forget that helpers are basically just wrappers for functional programming. So if you have a bunch of custom functions you use a lot, just add them to a helper and just load them wherever you need them (or autoload them if you use them all over the place).

It's part of the strengths of CI: it doesn't force you do things a certain way (well except for the MVC part which is a good thing).