Tag Archives: Design Patterns

More Active Record Features

Posted on by

It has been a while since I have written about, or coded, my Active Record implementation. Basically, I have had too many other things to work on to enhance the functionality of an already working, albeit very beta, design. But, that doesn’t mean I haven’t been thinking of all the features I want to add to it.

For many applications, the date created and date modified information for data is very useful, but annoying to set. Since Active Record abstracts all access to a database, these fields can be set easily and transparently. Many other implementations of the Active Record object already support this, so its not a new feature, but definitely a needed feature. The main issue is what timezone the server is in since NOW() doesn’t return GMT. It’s obvious that GMT is the preferred storage format of this data, so maybe passing a GMT date string from GMT is best.

Another feature that I just thought of is soft deletes. Basically a soft delete is where the data isn’t actually deleted, but a flag is set to show that it is deleted. This is very useful if you need to keep old data around for restores, or if you just want to have a record of everything. One of our new hires MikeT brought it up to me since his project has a soft delete requirement.

Hopefully I can get these added into my implementation fairly quickly since they are so simple.  Even though features like this are just the tip of the iceberg, they are crucial for creating a viable Active Record design.

A better web framework – Part 1

Posted on by

As I have mentioned before, design patterns are one of my favorite areas of computer science. Well, design patterns have a close association with web frameworks, so web frameworks are definitely another favorite area of mine. They both help speed up the development process by providing a structure for applications. Since Ruby on Rails took off a couple years ago, other web frameworks have sprung up in many other languages. None of these have met my needs at Webmail.us.

The webmail application I work on is very different than many other Web 2.0 applications, which is why most of the existing frameworks don’t work for us.

  • There are no page refreshes and therefore:
    • Most drawing is done by Javascript
    • All data transfered is JSON encoded
  • Email, Calendar, Tasks, Contacts, Settings are all combined into 1 application which means:
    • Large memory footprint
    • Javascript performance very important
    • On the fly loading of HTML, Javascript, and CSS is a must

For the past few months, I have been thinking about what I really need in a web framework. Just like Rails, an MVC framework would need to be the base. In Part 1, I will just talk about the MVC foundation for this framework.

Model

An ActiveRecord type object would provide the MySQL data abstraction. I have mentioned that I have been working on my own implementation for a while, so I won’t go into too much detail on this. Basically, for a complicated web application, most existing model abstractions don’t work very well. With complicated JOIN’s, WHERE’s, and subquerys, something different must be used.

View

A templating mechanism must exist to have a complete web framework. Current view abstractions won’t work in webmail. Since webmail never refreshes, going to the server every time we need to populate a template is troublesome. The templating mechanism in the better web framework would allow a template to be used in PHP or in Javascript.

If a template is used in Javascript, once it is downloaded once, it wouldn’t have to be downloaded again. The hard part about a Javascript template is the inability to have loops and the need for slow regular expression parsing.

If a template request in Javascript has to make a server request every time a template needs to be populated, speed becomes an issue. This is fine for large templates, but what about small widget templates? Making a server request for a small element increases 1. latency and 2. server load which in turn increases latency even more.

Controller

Controllers are the backbone of a web framework. I like how Rail works with a controller class where each data request is mapped to a function call. This seems effective to me and needs little modification.

Conclusion

I know what you must be thinking: Your MVC design isn’t that much different than Rails. Well, that’s true, but remember this is part 1. The MVC design is just the foundation of a better web framework. Rails is popular because it is useful, so it is definitely a good starting point for developing a new framework.

Shout out to Mike for his work on Javascript templates.

Active Record

Posted on by

One of my favorite design patterns is the Active Record pattern. For those of you who haven’t heard of it, this pattern abstracts database access to a very simplistic level. I first starting playing with my own implementations a couple years ago, but it wasn’t until I used Ruby on Rails that I first saw a fully functional implementation.

At Webmail.us, I have decided to use my side-project hours to work on my own version of the active record pattern. It has been a slow going process, since I rarely find free hours to work on it, but I have finally created a workable version. But, before we get to the inner workings of my implementation, I need to give credit where credit is due.

Rails Active Record:

Since the first active record pattern I encountered was the Rails implementation, I decided to start there with my first PHP implementation. It wasn’t long before I realized the PHP vs. Ruby differences were going to be a serious problem.

I wanted the find functions to be static, because an object shouldn’t have to populate itself after it has been instantiated. Unfortunately, in PHP, static methods aren’t capable of polymorphism (which makes sense since $this isn’t applicable). Therefore, overloading them becomes impossible.

CakePHP solved this by making all the find functions non-static, but I didn’t like this solution either, because it doesn’t make sense for the previously stated reasons. Then I found …..

Zend DB:

The Zend framework, while still very new, has some powerful features, namely the DB section. When I first saw this implementation of the active record pattern, I knew this was the starting point for my own version.

Zend DB has three main classes, Zend_Db_Table, Zend_Db_Table_Row, and Zend_Db_Table_Rowset. This design is much more flexible, and makes more sense to me than Rails’ and CakePHP’s implementations. Each database object is abstracted to its own classes, aka tables, rows, and rowsets (or arrays of rows).

At first, I almost decided to use this implementation and forgo the long process of creating my own. But, it fell short of my requirements for a few different reasons. The biggest problem was that the Row and RowSet class names are hard-coded in the Table class. This means overloading them is impossible:

1
2
3
4
5

return new Zend_Db_Table_Row(array(
    'db'    => $this->_db,
    'table' => $this,
    'data'  => $this->_fetch('Row', $where, $order, 1),
));

It also uses prepared statements, which I have never used and don’t really have a desire to. They are definitely slower than straight MySQL calls and I don’t have the mysqli extension installed so that is out (Although I should probably work on getting that extension installed).

Even though Rails, CakePHP, and Zend DB didn’t work out for me, they played in important role in leading me towards my current solution. In the future, I will discuss in more depth my own implementation and keep everyone updated with how it is working out.