The concept is simple, but its application is complicated. There is no metric for just how abstract a portion of code is, or how necessary or unnecessary the degree of abstraction a chunk of code is in the context of the problem it aims to solve. Perhaps the code needs to solve many problems, and a great degree of abstraction has merit, or perhaps the design is so bulky and complex the initial development time and long term maintenance overhead are staggering.
Using Doctrine2 for your new Zend project and Migrations 2.0 for database versioning? One aspect that quickly becomes annoying is the lack of integration with the standard Zend application.ini. Yes there is –configuration which allows you to specify configuration options via xml or yml, but those files aren’t aware of the many environments your Zend application is likely deployed to, nor do they know about handy shortcuts like APPLICATION_ENV, forcing you to hardcode absolute paths in each of several configuration files (one per environment).
A few months back we posted an article about a limitation in the design of SoapServer and it’s cousin Zend_Soap_Server. Zend_Amf_Server has a similar problem, namely no way to log input parameters and output results for service calls. As mentioned previously, being able to log inputs and outputs from a central location is a huge boon. The good news is Zend_Amf_Server does the protocol marshalling entirely in userspace so it’s much easier to accomplish this time around.
How do you get the debugger in Zend Studio to step through SoapServer code?
Inevitably as you develop Soap services with PHP you have to deal with a bug in the server side code. Since you can embed SoapClient in a script that renders a Web page and hit said page from a browser, it’s easy to debug SoapClient code using the debug toolbar. Doing the same for SoapServer code doesn’t work; you’ll see the problem in a moment. Conventional techniques like error_log et al to track down problems can seem painful compared to Zend Studio’s interactive debugger. Once you’re comfortable with the debugger and the advantages it offers this SoapServer enigma becomes very annoying, especially when you’ve got a bug to fix!
So you’re trying to write loosely coupled code and you keep hearing this thing about inversion of control. Perhaps you read about it in the chapter on factories while reading your favorite design patterns book. Well to summarize, inversion of control is where a chunk of code acts as a container for another set of code, the container controls some overall algorithm or sets of algorithms and calls other code to implement certain portions of these algorithms. This is commonly referred to as the hollywood principle, “don’t call us, we’ll call you”. This could be as complex as an MVC framework or a simple implementation of template method somewhere in your codebase.