I just posted a comment on Federico Cargnelutti's (excellent) PHP blog that I feel I should expand on. The topic was Zend Framework's suitability as an 'enterprise' framework. Although I'm sure ZF is used in a number of enterprises (and I've used it for a few things over at Incutio already), I think it is still a way from being the 'perfect' enterprise framework, which is how it is described in the post.
There are three 'enterprisey' areas in which I believe it is particularly lacking:
- ORM
- Database migrations
- Application deployments
None of these things are 'impossible' to do with ZF-based apps, but the ORM has its limitations; and the other two aren't covered by ZF at all and require integration of third party solutions such as Phing.
Zend's view on component development for ZF has been that they wish to focus on areas where they feel they can offer value to the PHP community as a whole. For this reason they have delibrately avoided developing components for things already well served by existing open source PHP projects. This makes complete sense. But as a developer coming to ZF afresh, unless you already know about these projects, you're going to see some pretty big holes in ZF as a platform on which to build your applications.
Firstly, ORM. I'm not going to say too much about this since I've posted about it before. I guess my main complaint about ORM in ZF is that I've found the Table Data Gateway pattern pretty limited (which isn't ZF's fault of course), and because of this you frequently end up having to either write your own ORM layer or turn to third party libraries such as Doctrine or Propel.
As an example, one of the first projects I tried with ZF was a rewrite of one our legacy applications, in which the data for domain objects frequently spans two or more database tables. The only way to load this kind of data with Zend_Db_Table is to create your own joins with Zend_Db_Table_Select, to the point where you'd basically back to writing raw SQL.
It is also suprisingly difficult to get the Zend_Db family of classes to return instances of your application's classes (by default they always returns data arrays which your application then has to convert into objects). It's not impossible to solve this, e.g. you can have your objects extend Zend_Db_Table_Row, or through some calls on Zend_Db_Statement directly you can specify the class you'd like returned, but both of these approaches are a little messy.
I feel a little bad bashing Zend_Db, as it does what it is supposed to do very well, and the adapter, profiler and select families of classes are all excellent. But these are real world problems that I've not found with other frameworks.
Secondly, database migrations. There is nothing in ZF to do these, the closest is a community-submitted proposal for a Zend_Db_Schema_Manager component which hasn't been updated since November last year. Sure there are some third party solutions, but this is functionality Rails provides out of the box.
Thirdly, deployments. Gone are the days when to make an app live you FTP in and manually upload the files (or at least they should be). Whilst Rails doesn't provide anything like this, Capistrano (which is excellent), was written for RoR, and is very easy to install and integrate with Rails apps.
This has been quite a negative post. I don't mean to suggest that Zend have taken the wrong approach in development of the framework - It's still relatively young, and the upcoming 1.6 release does plug a few of the less-enterprisey holes. But if the framework is to be taken seriously as a platform on which to build enterprise applications, these are the areas which I feel need improving. This could be achieved either through the development of new components providing this functionality, or through components that provide much easier integration with the existing PHP solutions (in the same way that symfony has a component for interacting with Propel).
In an ideal world, I'd love to see Zend-contributed components which implement some alternative patterns for use in ORM layers, such as Zend_Data_Mapper and Zend_Active_Record (post PHP5.3) classes. I also have a close eye on the Zend_Tool project, which I hope will eventually cover the other two areas I mentioned.
There are also quite a few big pluses for ZF as an enterprise framework, in addition to the things Federico mentioned in his post, the license of ZF itself and Zend's other offerings (training, IDE etc.) both definitely work in its favour.
Tags:
Comments
24th Jul, 2008
You're right about ZF lacking a migrations toolkit. And you're right that there are some 3rd party solutions (as opposed to the native support in RoR). As far as a 3rd party solution, I have found Ruckusing Migrations to be pretty good.
http://code.google.com/p/ruckusing/
It is almost identical to the RoR migrations, even down to being able to specify and use different environments (DEV, PROD, etc) to execute against. It has also a light-weight "task" system, ala Rake tasks. You can write basic classes and then execute them on the command line, the toolkit will automatically find them on the path and make them available.
Give it a shot.
24th Jul, 2008
Thanks for the feedback! I can tell you that we fully intend to offer database migrations and application deployments with ZendTool. Ralph's ZendTool initiative basically builds the framework upon which these tasks can be implemented. I think you'll find that only the code that for the command's operation itself + a few decorations like help strings, etc. will be required to implement these use cases. We aren't bashful about telling the world that we have big plans for Zend_Tool; this is indeed an area that we feel we can deliver a lot of value in.
As for ORM, I think facilitating integration with the likes of Propel and Doctrine would make for the best short-term solution. This will be much easier with the extras library to ship the components in. Same deal for Smarty, PHPTal, and other templating and view technologies. In the medium to long term, a true ORM effort on the ZF team's part would be *large* because we would have to deliver a *lot* of value considering the high quality and mature projects in this space. That said, we've already identified a few functional areas where we can bring that value, and I hope we'll be able to announce an initiative in the coming months.
Funny, my definition of 'enterprisey' seems to be a bit different from yours. I guess there are about as many definitions of enterprise as there are people who have the word in their vocabulary. ;) In any case, I have asked the team to deliver one major enterprise feature in each minor release. For 1.5 it was LDAP support. For 1.6 it is relatively comprehensive SOAP support. I guess I consider these enterprisey because they are most often required by mid- to large-sized corporations.
I hope you enjoy 1.6, and let me remind you that if you'd like to see the features you listed in ZF sooner, the best way is to start contributing! :)
,Wil
27th Jul, 2008
For a ORM, use Doctrine. At least that is what we are using with the Zend Framework. Doctrine also has pretty awesome support to apply updates to databases.
http://www.phpdoctrine.org/
As for deployment, most of our deployments are done using PEAR, subversion and capistrano. IMHO, not the worst solution.
27th Jul, 2008
Hi Tim,
Very interesting post and I agree that db migration support is a must. Based on my experience, using Doctrine doesn't solve the problem, specially in mid/large-sized corps where DBA's deal with db schema migrations and related issues. Doctrine, Rails, Django and other frameworks use code to define schema changes. This has some disadvantages, it not only slows down the migration process, but also exposes DBA's to new levels of complexity, considering that SQL is their area of expertise.
In order to address this, the most natural thing to do is to use a tool to automate the creation of up and down SQL scripts, I'm using a software to do this, so it's fast since we don't need to write SQL, XML or PHP code.
This also makes it possible to use a version control system to keep things synchronized with the actual code. Each database has its own table to keep track of the revision numbers along with the executed SQL queries. And finally, I use a Phing task to export and migrate all the changes:
$ cd developemnt/
$ phing db:migrate
or, using revision numbers:
$ phing db:migrate:revision
$ enter revision number(s): 1-10
and to rollback:
$ phing db:rollback
or, using revision numbers:
$ phing db:rollback:revision
$ enter revision number(s): 10-1
So yes, I understand what you are saying. ZF is not prioritizing basic enterprise needs, such as this one, and because of that we end up re-inventing the wheel. Just now, and almost after 3 years, they've added a paginator and file uploader component. So it's getting there, slowly, but it's getting there.
Fed
29th Jul, 2008
Thanks all for the comments.
@Wil: I agree that an ORM effort from Zend would be a big undertaking, but I also think this is one of the most important areas for you guys to look at in the future (perhaps for 2.0). I think ZF will continue to grow in popularity because of its strengths, but the ORM will limit the number of people you 'convert' from other frameworks (particularly the non PHP ones).
I agree that LDAP and SOAP are 'enterprisey' features, I've done some enterprise-type work with SOAP (largely through the nusoap lib). However I think of these as 'integration' features - you have an app and suddenly find you need to interact with some backend system or web service. The three things I mentioned are areas you'll hit when developing the app in the first place.
@till: I have used Doctrine, but these days I generally favour my own ORM layer, as (in theory at least) I get some extra flexibility with slightly less overhead. I have a data mapper implementation that works quite well with the Zend_Db adapter classes (I may open source this at some point in the future).
@Federico: Thanks for the info. What software do you use to generate the SQL? The ideal solution for me would be some software/script that scans a database when asked and generates the SQL required to convert the db from the previously saved structure into its current structure. That way I could continue to use whatever tool I wanted to make the actual development db changes, and use the software to generate migrations at appropriate points during the development process.
11th Dec, 2008
Just stumbled across this while searching to see if there are any plans for an enterprise ORM solution. I quite like Doctrine, I consider it to be much better than Propel (I have not used the latest versions of that mind). What I don't like though is that development on it seems to be fairly closed off, largely it seems to be a small core of developers and the community seems to have very little input to its direction.
I really like what Java are doing at the moment with the JPA (Java Persistance API) which is basically an effort to get a standard persistance framework in Java. It also supports the use of pluggable persistance providers meaning you can use say Hybernate as the actual implementation for persistance.
I'd love to see Zend to do something like this, say provide an API specification that could have many implementations but still a standard interface code could rely on.
Add Comment