Related
I'm a beginner php developer who is trying to build a social network for my school students. Knowing that the school has over 1000 students who are already active, I must have a plan of expanding / scale the code that I write.
Earlier it was just the LAMP Stack, now the modern web development is way more than that as I see, I'm truly kind of lost in what technologies to use and how to incorporate them to build a scalable app. I'm hoping to divide this application into 3 layers.
Application layer (phalcon,reddis,apache,php)[mvc api centric]
Database layer(mysql)
UI layer - (html/css/js/)
This is where i need help, is this design approach good for a scalable app ? where can i improve ? any explanations, links for further reading will be a highly appreciated.
Welcome to SO. I cannot think of a particular reference guide to direct you to (although the PHP manual is a good place if you end up stuck with how to do something specific). I would suggest reading a bit of several results when you search "Getting started with MVC in PHP" and noting what they agree on. That said, take a look at what I say below (and then ignore it as much as you please ;) ).
Firstly, you are wiser than many in sorting out a scalable design before launching into the project...
I'm excited to see Phalcon in your list there already. However, as DevDonkey suggested, start with something simpler first (Phalcon is very powerful but to really get to grips with it you need a good grasp of PHP, particularly object-orientated programming).
If you are completely new to PHP...
... try building a small app (products table, view/add/edit/delete functionality) and learn the beginnings of the language that way, as this answer suggests. Things will go wrong and you'll discover lots of headaches when you want to change one feature and it affects everything else but that will help you to understand the importance of...
MVC design
From your question I can see you have at least heard of this. This is really where the layers of your application lie:
Model - interactions with the database (retrieving/editing data) are handled through this. So you could have a MYSQL database and then your models provide a nice interface to interact with the data (generally you have one model for each table).
View - this is the last layer, what the user sees. So you will make use of your html/css/js knowledge here. On this topic, unless you really want to do your own css consider using a CSS Framework such as Bootstrap. It will really help speed up making your site look good and there are loads of free templates out there to use with it.
Controller - this is the application logic. The controllers request/manipulate data through the models and then decide what to send to the views for rendering.
Use a framework?
Using a good framework can make your application more reliable and quicker to build. But using a framework without understanding it will be frustrating, slow and possibly result in worse code than if you didn't use one to begin with (as you employ hacks to get around the pieces of the framework you don't understand). My current favourite is Phalcon but as a relative beginner to PHP I would suggest something more like CakePHP although both Laravel and Symfony are also popular.
Summary
Start small, learn, test ideas out and then build up to a bigger project.
Get comfortable using PHP (including OOP style) before using a framework.
Use an MVC framework
The layers you laid out in your question are good, but I would split it slightly differently (considering that MVC is the 3 layers)
Application Layer - controllers, written in PHP, handles logic/manipulation, often the biggest layer
Database Layer - models, written in PHP, you will also need a database which could be in your favourite database language - MySQL ;)
UI Layer - views, possibly written in PHP (depending on the framework) but also HTML, CSS and JS as well as well as a templating language if you wish (e.g. Twig or Volt), essentially a way to make the response from the controller nice for a human
First Project (for CakePHP)
This blog tutorial is a good place to start if you decide to use CakePHP.
Getting started with Phalcon
Phalcon is more powerful/verstile, but to get started with it I feel you have to be a better PHP developer than you do to get started with something like CakePHP. Take your time to understand each new concept with Phalcon, particularly Dependency Injection.
Even having used CakePHP for the past 2 years and being familiar with MVC patterns and PHP, I still worked my way through all 7 of the tutorials in Phalcon.
Having said this, my favourite thing about Phalcon is that it is highly decoupled - so it is fairly easy (after a while) to replace bits of it with your own extensions if it doesn't quite do what you want.
Note about Phalcon: It is not as popular as many other frameworks (although popularity is growing) and so you may have to spend some time digging around when you get stuck. However, the docs are improving all the time and the forum is very active. Unfortunately the number answering questions about it on StackOverflow is still small compared to many other frameworks.
I am considering learning CakePHP, but I see that almost all scripts and documentation are from either 2006 and 2007 and the backwards compatibility with those scripts is fairly poor.
Also most comparison charts of cakephp vs zend vs codeigniter vs others are made in 2006, 2007 or at last 2008. I am not looking to pick either one of them, since cakephp still seems to have the same advantages/disadvantages compared to the others as 4 years ago.
But I would like to know if I would be wasting my time learning cakephp. It seems lovely at first glance, but I have created many websites and am still unfamiliar with the MVC model. I want to maximilize my efficiency and competence in writing websites in PHP.
I currently make use of simple includes for the layout and still mix HTML code with PHP code. It works better then you'd think at first glance, but I think it's time to improve my PHP coding, quality of programming and a higher efficiency in programming speed is always welcome.
Is learning CakePHP at this moment wasted time or a good plan in order to make a next site better, not just programming-wise, but also in quality/features/programming speed/scalability, than all my previous sites?
I can definitively say that CakePHP is still in use, and its featureset and documentation are growing stronger. I am using CakePHP (1.3) on several projects and it is relatively easy-to-use, once you're familiar with MVC.
There is a learning curve though, and if you (like me) came from a world of intermixed PHP/HTML then any MVC-oriented framework will require you to first unlearn the tightly-coupled logic and presentation before you can take full advantage of the MVC way.
Some tips that I picked up after over a year of working with Cake (and some should apply to other frameworks as well):
The "official" documentation sucks, but it's getting better. Thankfully there are a ton of people using Cake and blogging about how to do things -- don't be afraid of Google.
Put as much business logic as possible into the model (aka "Fat Model, Skinny Controller").
Make sure your database structure is as close to final as possible before you start coding the interface. It's not difficult to go back and change associations, add fields and add validation code -- but it's a bit tedious.
To your other points:
No, it's not a waste of time to learn MVC and Cake. Once you understand it, it truly does make application development faster and helps you write more stable and maintainable code.
Most people don't necessarily equate speed and scalability with PHP-based frameworks, though that's not to say that they aren't "fast enough" for most uses. A bit of targeted Googling should turn up some speed comparisons.
There are some very large sites on Cake, and some of them have even chronicled their scaling efforts.
TL;DR: Take the time to learn MVC, even if you decide against using a framework your code will improve because of it.
One of the keys to good web application design is separating your business logic from your presentation. Close behind it is abstracting your data sources so you can change the data model without having to rewrite all your code. CakePHP and many other MVC frameworks help you do that. Overall it makes for more manageable code.
I can't make a decision for you but I do use CakePHP in my own projects. The documentation is actually extremely good for CakePHP. It is one of its strongest points. I'm not sure where you are getting your 2006/2007 numbers.
http://api13.cakephp.org/classes has all the API / class documentation for 1.3 (which was released less than a year ago - with 1.3.10 being released just weeks ago)
Granted that the CakePHP "book" hasn't been updated for 1.3 yet but just about all of the tutorials and how-to's for 1.2 will work with 1.3. <= yes it has, sorry
The CakePHP "book" has tons of examples and a great tutorial.
Additionally, the Cake Bakery has many excellent user submitted tutorials.
The older benchmarks do paint a grim story, however, 1.3 is significantly faster and better performing than previous versions.
The important thing -- in my opinion -- is that you get away from "tag soup" and structure your applications so that they are manageable. What framework you choose is your call. It could be CakePHP, Zend, or even one that you write yourself.
Note: MVC can be difficult to grasp at first. You'll need to have a good understanding of object oriented programming. But learning is a good thing!
Have you tried asking the community online or in person? You could also check out the CakePHP community passively on GitHub and see if people are using the code the way you would like or for things you like.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Discussed this with a developer as I suggested to use CodeIgniter framework over standard PHP.
Their response was as follows:
Advantages of Code Igniter include standardised MVC structure.
Disadvantages include the fact that you need the whole framework even if you dont need to use it all and also a bit slower for the team to roll out the project. Advantages of our normal Custom PHP framework - fast to develop and totally flexible, only need the code that is relevant.
Would you agree with their response and why?
I always though CI was quicker to roll out due to the use of short tags and freely available modules.
CodeIgniter has a learning curve but that curve is likely to be quicker than your custom framework. That's because CodeIgniter is well documented.
CodeIgniter is a fairly comprehensive library. Once you learn the framework, you can employ any of its libraries not only in the current project but in various other projects.
The work is already done for you. You may not even know that a XSS or CSRF exploit exists in your code because you haven't done a thorough security audit. But a community framework is under constant audit.
You can extend CodeIgniter to your own needs and still have custom functionality.
After using CodeIgniter for a sufficient period of time, you'll inevitably pick up some great programming practices and improve your overall knowledge since the framework employs many best practies.
It is likely that if you encounter a problem situation, someone else has already solved it. CodeIgniter also has a good community through which you could save yourself hours of debugging.
That said, CodeIgniter is not the only framework but I really do like that fact that with the newer release they have moved to PHP5. In general, open source frameworks are the way to go.
I would strongly disagree.
The details of the project would be very helpful, but in general frameworks are very helpful and speed up the work (not necessarily the application) significantly.
Consider the fact, that 'Custom PHP Framework' (whatever they think of) is... custom. That means it is not tested as eg. Zend Framework, it has not proven to be efficient and successful in thousands of projects, and it is probably something very simple (as large frameworks have been developed for years by big teams of developers plus the developers of companies that use them).
Of course coding PHP can be quite good option, when you really need speed (of the application), have time to build it and money to pay the developers that will be developing it quite extensively (because they will be implementing many features that come with almost every PHP framework). But you have to be sure, that you really need to take that non-standard approach (as 'non-standard' I mean not using some reliable framework).
It is up to you. If you can give some details about the application that has to be created, the answers may be more relevant.
Non-Business projects: Standard PHP.
Business projects: CI.
Trying to build you own Framework is very educative and will help you a lot; it will also let you create a framework that fit your needs instead of a general one. But that could be done only if you are managing to create a non Business projects because Business ones requires stability that you may not get from a home-made framework. By creating your own framework you might loose a lot of time (which is expensive when working with business stuff) and money for nothing.
It basically depends on your project type.
I have some experience with writing my own CMS, and I must admit, that this was very educating, but from financial point of view, totally uneconomic decision.
In my opinion, those developers should try to write some specification. Very detailed specification of what they need to implement. Then they should calculate time needed to code such functionality so they can compare this work to elements already included in CI and decide which option is more viable in terms of time to code, time to learn, and of course time to test.
If they don't mind teaching their custom framework, then it's probably the best fit (especially if the guy who wrote it is still around).
However, custom frameworks can turn into unsupportable nightmares. CI has the advantage of a small community and thorough documentation. Once you roll out a few projects with it, I'm sure the roll-out time will be as fast as the custom framework.
We ditched our own custom framework in favour of CI. Financially it was a tough decision as weve spent 1000's of hours on it and have a lot of projects running on it.
CI has allowed us to develop faster and has standardised our projects. The architecture also allows us to extend easily without concerns about 'damaging' the core framework.
CI is the way forward IMO
Their response was quasi-correct...
Disadvantage: also a bit slower for the team to roll out the project.
This is generally untrue, and infact, it's probably quite the contrary in many cases. Personally, I am able to crank out projects much faster using a framework. I haven't used MVC in a team environment but I would imagine that by dividing work into Models, Views and Controllers workflow seperations would promote development speed.
What are you building? This is the crucial question.
If you're building a dynamic web application, frameworks will save you hours and hours of work because you won't have to reinvent the wheel over and over again. If the point of your project is basic, then indeed... frameworks add too much overhead. I'd say, as a general rule, if you're project will require greater than 5 .php files, then start using a framework, because that's what it's purpose is - to separate the logic.
Use CodeIgniter or another framework for larger projects where you suspect your code will start to get disorganised. The MVC pattern prevents this disorganisation.
It sounds as if you've never used a framework before. The first step in making decisions on whether or not a framework will suit the task is to get familiar with one. You'll then be in a much better position to make this call. I do not recommend you write your own right away; you will gain a lot of insight after playing around with CI, Cake, or Zend.
We have got a project to build an ERP system for one of the largest garment industry of Bangladesh.
They have around 20,000 employees and about 10% of them get out/in every month. We are a small company with 5 PHP developers and don't have much experience with such a large project. We have developed different small/medium scale projects previously with Codeigniter/Zend Framework and MySQL database.
For this project we decided to go with Yii framework and MySQL or PostgreSQL. There will be about 1 million database query every day. Now my question is can MySQL/PostgreSQL handle this load or is there a better alternative? Is it ok to do it with Yii framework or there have a better PHP framework for this kind of application? We have got only 5 months to build the payroll and employee management modules.
For one thing, consider using PostgreSQL rather than MySQL. You're going to be dealing with mission-critical data and, in general, you'll appreciate that:
You will have access to window functions (useful for reports), with statements, and a much more robust query planner.
You will have extra data types, namely geometry types which can be used to optimize date-range overlap related queries.
You will have access to full text search functionality without needing to use an engine (MyISAM) which is prone to data corruption.
You will have more options to implement DB replication (some of which are built-in).
With respect to scalability, be wary that scalability != performance. The latter is about making individual requests faster; the former is about being able to handle massive quantities of simultaneous requests, and often comes with a slight hit to the latter.
For the PHP framework, I've never used Yii personally, so I do not know how well it scales. But I'm quite certain that Symfony2 (or Symfony, if you're not into using beta software) will scale nicely: its key devs work in a web-agency whose main customers are mid- to large-sized organizations.
I think, Yii will work fine with (relatively) large amount of data. I'm using Yii to manage 1.3 million records, some thausend updates a day and some thousand querys a day on an small virtual host with an amazing performance.
If your database can handle this data, your Yii application will also handle that.
Your choice of the database will be an important point. So #Denis said some important thinks. By using MySQL probably you have to explore / determined the right storage-engine for your needs.
But, there are some points, which i realized by creating an growing project with Yii. You should think about those things:
-Yii is an young framework: new technologies (like ajax) are supported, but in some special cases it's a bit immature: it's very easy to generate an basic application in a cuple of hours. Problem could be occur by special situation and requirements.
Example: they have an nice validation-mechanism for user inputs(HTML Forms). But until Yii 1.1.6 that doesn't work with HTML Checkboxes, since Yii 1.1.7, Checkboxes are supported by default, but no groups of checkboxes. An other problem: Yii alway uses an table alias, which is always "t". That could be a problem! Sometimes you can define that alias, sometimes not (which is inconsistent). If you like to lock a couple of tables in MySql, you ran into a problem, because Yii calls every table with the same alias "t". So you are unable to loot the tables in MySql by tablename and it's also impossible to lock a couple of tables, which called by the same alias. -> those are specific problems, you can solve them, by writing pure PHP (not using Yii functionality) What I'm trying to say: the framework will not be helpful in very case, but in mostly.
-Yii is easy to extend. It's easy to add own extensions or functionality. So lot's of those "small problems" can be solved be writing own extensions, widgets or by overriding methods.
-Yii supports PHP 5.2. Yii is compatible with 5.3 but (Yii runs on 5.3 - i'm still using it since yesterday, it work's) but doesn't support new features from 5.3 (maybe you need one?)
PHP5.3 will be (maybe) supported with Yii 2.0 - in a distance future (2012)
-Yii has a small (but very good) community.
-there is no professional support (you can post bugs in hope, anybody will fix it - or you will fix it yourself)
-Yii is OO PHP. Think about that by handling with Data-Objects. It's possible to load large amount of data into Data-objects. But keep in mind, that your application server have enough RAM (but that's not a Yii specific thing)
At all: i like Yii an if your application is not to complex, you will have a lot of fun an an nice and powerful application at the end.
I think you might be asking the wrong question, though.
You have five months to build an ERP system. The primary concerns should be:
security. You're dealing with money and personal details.
reliability. Uptime is probably a big deal (at least during working hours)
consistency. You don't want to risk losing data or corrupting data
developer productivity. Five months is not much time do build what you describe
maintainability. Sounds like this is a core enterprise asset, with a lifetime of years - it's likely to require maintenance and extension in the future.
scalability. You need to support tens of thousands of workers, each with many time cards, pay roll runs etc.
performance. You want the application to be responsive.
I would query whether performance is an absolute priority - it shouldn't be slow, but many ERP systems are a bit sluggish. Performance optimizations often mean trading off other priorities - for instance, an ORM system improves developer productivity, but can be slower than hand-crafted SQL.
As for scalability - as long as you have a reasonably designed schema, I don't think 20K employees is much of a challenge to any modern RDBMS on decent hardware.
So, if I were you, I'd probably go with PostgreSQL, for the reasons Denis mentions. Never used Yii, but it seems perfectly reasonable. I would use ORM until you find a situation where the performance really is unacceptable.
Critically, I would put together a testing framework which allows you to monitor performance and scalability during the development cycle (I use JMeter for this), and only make performance optimizations if you really have to. Sacrificing all the other things - especially productivity and maintainability - in the name of performance before you know you have a problem tends to create over-complex solutions, and they in turn tend to have more security issues and maintenance challenges.
Just to add ,
Yii scales very nicely in both directions (ie functionality addition using new modules etc and is one of the fastest php frameworks when it comes to performance ).
The only drawback I can see with Yii is that it has lesser user base so a bit lesser support than some other frameworks, but this is changing fast.
The best part of Yii is the gii based code generation which helps you get started really quickly once you get used to it.
Yii is very flexible, light and easy to learn PHP framework.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am refurbishing a big CMS that I have been working on for quite a number of years now. The product itself is great, but some components, the Database and translation classes for example, need urgent replacing - partly self-made as far back as 2002, grown into a bit of a chaos over time, and might have trouble surviving a security audit.
So, I've been looking closely at a number of frameworks (or, more exactly, component Libraries, as I do not intend to change the basic structure of the CMS) and ended up with liking Zend Framework the best. They offer a solid MVC model but don't force you into it, and they offer a lot of professional components that have obviously received a lot of attention (Did you know there are multiple plurals in Russian, and you can't translate them using a simple ($number == 0) or ($number > 1) switch? I didn't, but Zend_Translate can handle it. Just to illustrate the level of thorougness the library seems to have been built with.)
I am now literally at the point of no return, starting to replace key components of the system by the Zend-made ones. I'm not really having second thoughts - and I am surely not looking to incite a flame war - but before going onward, I would like to step back for a moment and look whether there is anything speaking against tying a big system closely to Zend Framework.
What I like about Zend:
As far as I can see, very high quality code
Extremely well documented, at least regarding introductions to how things work (Haven't had to use detailed API documentation yet)
Backed by a company that has an interest in seeing the framework prosper
Well received in the community, has a considerable user base
Employs coding standards I like
Comes with a full set of unit tests
Feels to me like the right choice to make - or at least, one of the right choices - in terms of modern, professional PHP development.
I have been thinking about encapsulating and abstracting ZF's functionality into own classes to be able to switch frameworks more easily, but have come to the conclusion that this would not be a good idea because:
it would be an unnecessary level of abstraction
it could cost performance
the big advantage of using a framework - the existence of a developer base that is familiar with its components - would partly be cancelled out
therefore, the commitment to ZF would be a deep one. Thus my question:
Is there anything substantial speaking against committing to the Zend Framework?
Do you have insider knowledge of plans of Zend Inc.'s to go evil in 2011, and make it a closed source library? Is Zend Inc. run by vampires run by evil vampires that want to take over the earth? (It was established in the comments that Zend is actually run by vampires.) Are there conceptual flaws in the code base you start to notice when you've transitioned all your projects to it? Is the appearance of quality code an illusion? Does the code look good, but run terribly slow on anything below my quad-core workstation?
Accepting answer
Thanks a lot everyone for your detailed feedback. I wish I could set up a bounty and distribute it evenly among all answerers.
Among many opinions favourable towards ZF, there was one very well founded one against. I took that very seriously and had a close look at alternatives, mainly Yii and Kohana. From that comparison and from reading some more opinions regarding ZF and competing products, I can see that Zend can be viewed as bloated in some fields compared to more minimalistic frameworks. (I can also see that this "bloat" is mostly with good reason to provide maximum flexibility. But the question whether you want maximum flexibility and deal with the ensuing complexity, or a simpler approach with clear guidelines, is a valid one.)
Anyway, I will go for Zend for the project at hand, because the main use I have for the framework there is as a component library. I do not want to adopt Zend's MVC model, I just need high-quality components for Internationalization, Session handling and so on. Because I am building a redistributable product, Zend's flexibility (e.g. the support for five different dictionary formats) is welcome to me. Also, ZF seems to be the only framework that allows the degree of freedom I want (No forced use of patters, file structures...) as far as I can see, no other framework offers that.
For future projects in which I want to make use of the actual MVC features, and totally submit to a framework's conventions on application building, naming, style, and procedures, though, I may not necessarily be going for Zend, but for a more minimalistic framework like Yii or Kohana.
Zend Framework is the best choice. Best framework API of them all, readable code, language conventions, good docs, comunity, support et all
My dislikes of it (subjective, mabe people are going to downvote me for it) are:
Zend_Form, has it's use, but in general is too obtrusive, I just want to structure my HTML not fight APIs and decorators.
Zend_Db_Table, powerful, but it needs a lot of work to accomplish your goals, and Rails taught me to be lazy. No, I don't want to write 3 classes for a model, one for the table, one for the rowset, one for the row, then bind them to each other and so on. I might need the table data gateway at some point, but for now I really want to interface this data with a quick active record.
no active record. With the late static binding in php 5.3 this might change ...
I tried really hard to use these two for a couple of months until I finally had it.
I overcame them by (ideas from Ruby on Rails)
use plain view helpers instead of Zend_Form as in:
echo $this->formText('email', 'you#example.com', array('size' => 32));
having my own Active Record like models ( http://www.phpactiverecord.org )
validate and filter on the model
for the really extreme corner cases, one can fall back to Zend_Form + Zend_Db_Table, although I never felt the need.
EDIT
There are some new kids worth checking out, like Laravel
The one thing ZF really wins over other frameworks is the router, controller and views, conventions, clean readable code, process.
Unless you're looking forward for a massive, giant project with 20+ developers, I'd - if I were you - would do anything including sacrificing an arm and/or a leg just to avoid Zend Framework.
The nice option you found out might look handy - to the point where you find other 1k+ setting that just looks like a waste of time and developer effort in the library. You'll soon find yourself in the middle of Customization Ocean, overwhelmed by settings, interfaces and abstract classes.
The documentation is not only detailed, but as a result very lengthy and complicated (similarly to the library itself). I want 3rd part classes to help me and not to get into my way.
The most important factor was the development speed for me, obviously. Without a bunch of colleges around you, Zend Framework should be seriously considered whether to be dropped.
There are too many people making wishes in the Zend issue tracker, too many people implementing code. To date, I've yet to see any serious vision behind those millions of lines.
My two cents really comes to down to one point: despite (or rather, because of?) it is backed by the PHP company, it is far too bloated for personal usage and small- and medium-sized projects.
My team is currently using Yii for a medium-sized project. It's not perfect either, but way more usable and developer-friendly compared to the big brother.
I don't have any big argument against ZF -- on the contrary ; of course, I have not used all the components yet (not sure anybody has), but I've never seen anything that looked "bad" when going through the sources.
When beginning a new project, I would generally go with Zend Framework myself, actually, if I'm the one who has to choose...
There's at least one argument I would like to add to your list :
Zend Framework can integrate with other components : you talked of using components of ZF in your application, but didn't talk about the opposite.
A great example is Doctrine (the default ORM of Symfony), which can be used with ZF quite easily -- and is much better than Zend_Db, in my opinion !
Besides that, I have to say that I agree with everyone of your points.
About the encapsulating ZF classes into your own classes : yes, you could do that (I sometimes do), but I wouldn't recommend doing it for everything : in most cases, it will probably not be necessary.
About the future :
Zend Framework is released under a BSD licence -- which means what exists cannot be closed-sourced.
Closing it would mean its end, anyway -- would be a stupid move, in the context of the PHP community
Work on ZF 2.0 is just starting (With PHP 5.3 as a requirement, btw)
Maybe, depending on your schedule for your application, it could be interesting ?
At least if you don't need to start developping before at least a couple of month...
We've been developing with ZF for almost a year now, and I really have no major qualms with it. Had a bit of a learning curve, but once I understood it, I realized how well put together this framework really is.
Compared to other frameworks, some people might point out the lack of a Model library as being a downside. I actually prefer not being told what to use, and integrating Doctrine with ZF is frictionless. If you're developing in PHP 5.3, and want an ORM, I would highly recommend Doctrine 2 (caveat: it's still in alpha testing).
The other great thing is being able to pick and choose what you want or don't want. I'm not a huge fan of Zend_Form, but I don't have to use it if I don't want to. Also, there's a very loosely structured plugin architecture that lets you really easily hook your own libraries into the framework.
So, I'm a pretty big fan of it.
One thing I am missing in the Zend Framework is a proper OR mapper. Zend_DB is ok but has some shortcomings, especially when dealing with huge databases (many tables) it gets very cumbersome. But there are a couple of OR mappers out there that can be integrated (e.g. zend-framework-orm or Doctrine as mentioned by Pascal MARTIN).
But yes, Zend is excellent, very powerful and I feel it is in some ways what PHP actually should be/should have been in terms of interface and functionality.
What I especially like apart from the obvious is the support for Dojo for rich client applications and the SOAP support.
I used ZF on a project as sole developer. Although the learning curve was quite steep, I didn't encounter too many of the problems described above. In general I found the framework very flexible, and the loose-coupling of the components made it easy to do my own thing when the ZF way of doing it didn't suit my needs.
But having recently started using python, I'd say use python ;)