My blog has moved to http://blog.derekbobo.com

I moved my blog. Visit http://blog.derekbobo.com for the new one!

The Framework

Posted by derekbobo on January 8, 2009

Just like any house must have a solid foundation, a good piece of software needs to have its base or framework thought out. As I mentioned before, my goal is to create an easy to maintain and scalable solution so that I can focus on value-added activities such as sales, new feature development, etc. Without a solid design I’ll get bogged down with tweaking the product rather than enhancing. That model just doesn’t scale. Period.

The other factor I’m trying to address is usability. Due to the market segment I’m approaching, I think it’s increasingly important to have a very intuitive interface. Similarly I’m trying to keep my feature set compact and focus on the big issues. My thoughts are very similar to Getting Real. If I keep my feature set compact focusing on the big issues I’ll be able to more quickly adapt and expand with my clients. If I try to implement every feature under the sun, not only will I have difficulty delivering the product to begin with, I’ll have more trouble evolving later.

My approach is a fairly classic example. I’ve built the framework implementing the M-V-C design pattern. This concept attempts to separate presentation (V-View), from business logic (C-Controller), from data access/manipulation (M-Model). There are a lot of debates over how to implement this, but in my mind, if you’re separating out these components, then you’re implementing MVC. Furthermore, I believe in writing code that just makes sense. Certainly there are some best practices to follow, but what sounds great in theory often falls short in practice. I guess what I’m saying is that I’m not a purist in that sense. In my mind it’s okay to have a little bit of logic in a view or model, but the majority of the logic should exist within the controller. It controls the application, ya know? That being said the only logic that is acceptable in a view is logic that relates to presentation – NOT BUSINESS LOGIC. Similarly logic can exist in a model if it relates to generating or manipulating data – NOT BUSINESS LOGIC. There are a lot of different opinions on this, but hey it’s my application so I’m going to do it my way.

I’m leveraging PHP, MySQL, and Apache for this particular implementation, but the concepts work for other environments as well. Interestingly enough I’m helping address a very similar problem at my “real job.”

The first thing to understand is the concept of SEO friendly URLs and URL rewriting. There’s a real slick way to handle this in Apache using the mod_rewrite module. Essentially what happens is a user types in a URL such as: http://www.somedomain.com/client/controller/action/param1/param2 – that’s the basic format. Now of course a URL wont always look like this, we can assume some defaults, etc, but I’m only going to use this example as it is easier to explain.

  1. So this URL gets entered into a browser and the user hits ‘Go.’ The request is first looked at by Apache’s .htaccess file. This file will basically take the request and forward it on to the index.php page. This page invokes some classes to parse the URL into individual tokens so that we can make sense of the request.
  2. The request then uses the tokens to determine appropriate action to take. The request is handled via a Router which uses the controller parameter to invoke the appropriate class. The action parameter is essentially a subset of the controller. It’s an event (action) that does some work for the controller.
  3. The typical case is that a controller/action will use the client parameter to load in the appropriate look-n-feel (master view). It also loads a sub view which is usually the template for a particular page.
  4. As was mentioned earlier the view does not contain any business logic. It should basically just define placeholders which need populated. This is where business logic and the use of models come in to place.
  5. A model is invoked to determine the appropriate data to populate the view with. We basically pass in any parameters to get some data back and then we use that data to populate the view.
  6. At this point our page is populated, rendered, and ultimately returned to the clients browser.

Now that I’ve completed an explanation, here’s the shorter version:

User Request -> URL Rewrite -> index.php -> Router -> Controller -> Action -> View/Model -> Return to user

It sounds like there is a lot going on, but the majority of it is transparent. This approach separates out the main parts of the code so that they are logically grouped and much easier to maintain. Furthermore, since the framework handles most of this behind the scenes it actually takes very little code to create new pages/implement new features. The whole concept is really pretty elegant if you ask me!

I’m pretty excited because my framework can be shared in some of the additional markets/products I intend to pursue in the near future. This means even less code to maintain, thus a much more scalable/maintainable model.

So that’s kind of where I sit today. The framework is in place and the dummy functionality is ready to go. Now I need to start working through my front-end user features one by one and then ultimatelly built the administrative tools that will complete the product. It’s all pretty simple stuff, but it can be pretty slow due to all the other stuff going on in life. I just gotta keep chipping away at it.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: