All Things Patrick - Working Hard to be Lazy!

I've been trying to put my finger on why I think a particular set of classes a previous programmer wrote to interact with a payment gateway annoys the hell out of me. At first I just felt overwhelmed by the number of classes and their interactions. I then listed out the classes and used a simple diagram to show basic interaction. Class A has a process that uses data from Class B, runs it through Class C, dumps the results into Class D, & somewhere along the line Class E gets used as well.

The simple diagram showing basic interaction reduced it to a point where it made sense and would look very similar to a simple diagram showing basic interaction between classes in any number of other frameworks. Coming from this direction it just makes my frustration look like a pet peeve blowing something hugely out of proportion. Not what I was hoping for and the project needs to launch last week (literally, the site usage is based on the school year & the old site has already been getting some usage).

I was wanting a much easier way to deal with the gateway and then a much easier way to write it's response to the database. I was failing at finding the right way of expressing my feelings as to why the classes were built wrong. The only thing I could come up with is that I was doing a ton of data processing to get the data from the form, pull information from the database, give just enough of the information to each of the different individual classes before handing yet more controller processed data off to the next class.

Tonight on IRC I was in #phpc on freenode and ymas issued a warning as part of his complaint about a framework (s?)he had quickly jumped into without fully understanding the model portion of the framework he was working with. The exact statement was, Public Service Announcement: Do not use a PHP framework to learn about MVC. You should learn about the compound pattern MVC and then pick a framework. I have been stung ... quite badly.. I would, however, posit that this applies to any MVC framework for any particular language (i.e. insert favorite language here).

I asked him which particular framework had stung him and he didn't want to publicly say in channel for fear of starting a flame war. Considering the crowd I'd think there would more likely be a bombardment of devil's advocates or wise people giving good advice in their own funny way. My curiosity got the better of me and I was able to get him to tell me which framework he had dug himself into a corner with. I've not used the framework he mentioned, but I think it sticks to a purely Active Record mentality and goes nuts if you try to do more than just Active Record.

He, ymas, had found an article that made him decide to look elsewhere - The M in MVC: Why Models are Misunderstood and Unappreciated - Maugrim The Reaper's Blog. I'm still reading through the article, but I think I've discovered the source of my subconscious annoyance (hunch?) that makes me think this set of classes interacting with the payment gateway is badly designed.

Just as all squares are rectangles (ok, I use this comparison way too much) all ORMs attempt to fit into or replace the model layer of MVC. Most frameworks tend to have some sort of ORM or some other database as a class method of mapping code to database tables as their advertised model component.

The article above reminded me that the model is the business logic portion of dealing with the data that the rest of the application uses. An ORM should help with the initial database data management building block portion of the model, but it shouldn't be the sole piece of the model layer. As an example the author of the above article points out that the Zend_Feed_Reader is a model for reading, manipulating, and interpreting data from a feed (i.e. an RSS feed).

Aha (Eureka!?), this is why my subconscious was overly frustrated with these payment gateways. My controller has to do a ton of data manipulation leading to a Fat Ugly Controller (FUC) and instead the classes dealing with payment gateway should probably be treated as a model.

Now it's way past time for bed, but my subconscious has something new to process.

As a side note I talked with ymas about Symfony & the Zend Framework. Symfony is more of a complete MVC framework with each piece of it (not necessarily MVC pieces) a separate project making the entire thing pluggable with replacement pieces (want to use a different ORM or make the model more than just an ORM? then use a different ORM or add to the model so that it's more than just an ORM). Zend Framework on the other hand is made up of lots of components that can, with a bit of glue, be made into an MVC frameworks (it has all the pieces, you just need to put them together).

There was also a large discussion between several people in #phpc about MVC frameworks and models and I'll have to see if I can pull the log of that later.