Professional PHP Design Patterns

23.2. Removing Logic from Views

I strive to keep my logic outside of the view of the application. However, whether because of an oversight or programmer laziness, a few lines sometimes sneak in. This is very bad: the view should never have to perform any data or object manipulation duties. Instead, the entire set of information should be provided to the view. The view can make decisions on which bits of that information to display.

In this application, the requirement to have more than one view right away makes this doubly important. If the default view contains some logic to build an object, the mobile view must contain this exact same logic. If a third view is added, this logic must also be copied to that view as well. This creates code duplication and is not best practice.

In this application, I made the mistake of allowing the complexity of the contact dao relationship retrieval process to deter me from what I knew was best practice. This next section describes where this problem happened and how to fix it.

23.2.1. Modifying the Single View of a Contact

When building the view for looking at a single contact, gathering the information together ahead of time outside of the view became very complex. This should have been a dead give away to use one of the Design Patterns to deal with this complexity. Instead, I created a contact dao and a contactgroupscollection object. Inside of the view, I created individual contactmethodcollection objects. The way I look at this, I was executing ...