Friday, August 19, 2005

Application tiers, SOAP interfaces, and XSL transformations

I get a lot of instant messages asking me how the shopping cart project is coming along so thought a quick post about progress would be in order.

First, I have agreed to help a close friend (Chris Larocque) code his application and in return he has agreed to help with foundation coding of the shopping cart. The great benefit to both of us is that the two applications are nearly identical in architecture and use of design patterns. For example, one requirement for Chris's project is a fully tiered application with tight integration of local versus SOAP gateway interface for the accessor tier.

So, we have identified core architecture features of both applications:

  • Traditional tiers (presentation, business logic, accessor, and persistence)
  • Gateway interface between tiers that support local and remote access (via SOAP)
  • Robust template engine for complete separation of presentation and business logic

In addition, we are going to implement a modular structure that will provide for hooks and may in the future be developed into a plug-n-play feature that is common with a CMS. However, right now it will be coded for data presentation modules as core modules will inevitably have code clashes.

A primary focus will be on performance and scalability. The tiered architecture with remote data access will provide the ability to physically separate the tiers on different servers and will also allow for clustered server load balancing. The end result is an infinitely scalable application that can handle Ebay or Amazon traffic volumes yet realize an insignificant degradation in page rendering performance. Of course if all the tiers are local to the same server it can save the overhead of creating web services and run faster with local access.

A secondary focus will be on the templating. I am seriously considering using XML data / XSL server side transformation for the actual templating but there is a learning curve. I'm most used to traditional templating engines but the power of XSL transformations are apparent.

OK. so now let's talk about timeframes. We expect to complete Chris's application within a week or two and then move on to polishing the various functions. Thus, once Chris's application is built it will serve as a guide for the shopping cart. Hopefully, this will decrease development time and give an indication of areas that need special attention.

Tuesday, August 16, 2005

PHP Design Patterns

Would this be more efficient with a Singleton, Iterator, Factory, Strategy, or Model-View-Controller design pattern?

The basic question of whether a design pattern will fit a particular task better than the usual prcedural script method is one asked by many coders over the course of any application build. Unfortunately, it has been some 7 or 8 years since I took the C++ class in college that covered patterns. Thus, I have found that my knowledge is really out of date with current patterns.

I started my search on a good reference for current PHP design patterns and found a great book: php|architect's Guide to PHP Design Patterns ($32.99 USD)

This book is one of the best references for PHP design patterns that is in my library. There are many examples for not only PHP5 but also PHP4 adaptations. The problem with PHP4 is that a lot of traditionally OOP features are not implemented...but there are a few workarounds. If you are into high level or professional PHP coding I highly recommend you get a copy.