Contemplating Application Frameworks

by Mike Levin SEO & Datamaster, 07/18/2005

I’m in framework mindset again. Every five years or so, this happens to me, and I crank out the next iteration of what I’ve come to think of as my generalized framework. There are dozens of application frameworks out there. Mine, oddly, have been based on VBScript under ASP. Most seem to be based in the LAMP world (Linux, Apache, MySQL, PHP/Python/PERL) or Java. My framework has been based on convention over creativity. In other words, most apps look and behave alike (echoes of Mac). Most RDBMS (relational database management systems) are basically the same. You manage lists of lists. And the details of the relationships dictate that you occasionally have to insert or update table B in order to have the data you need for you original table A action – calling for session-interruption and modal behavior. The rest is prettying up the screen, improving usability, and triggering off special business rules. Once you accept the difficult-to-swallow notion that almost every app is the same, whether it’s Palm contact-management or SAP/Oracle ERP/CRM (enterprise resource planning / customer relationship management), then you can focus on the general rules of making an application spring-to-life, once the ERD (entity relationship diagram) is set up. In other words, you put a bunch of tables in location, tell the generalized system where to find it (even that may become optional), and the application magically springs to life, inferring how everything should behave, based on the foreign keys and populated data. You then start overriding the default generalized behavior to turn it into the desired customized application. This may involve adding triggers or changing the auto-decision dropdown menus. And because you used full separation of concerns, your over system can grow by leaps and bounds over time.

So, that’s what I call a generalized system. And so far, the versions I’ve made have been technology specific on the back-end. The first iteration was on the primitive Microsoft IDC/HTX (internet database connector & templates) tools. The next two iterations were VBScript, the first requiring complex config files, and the second requiring very sparse config files, but with tons of edited-options that could be activated by removing the single-tick-marks. So, why not Java Struts, and save myself the effort? I ask myself this type of question regularly. As it turns out, I can customize my own self-built framework much more rapidly than others’. I can also make apps spring to life in minutes, and was never able to reproduce that experience with established frameworks – until Ruby on Rails. The principle being that apps are so easy to create thanks to a process of interrogation, discovery, and conventional behavior that making an app is like tripping and falling. You are being productive without hardly trying. Now, I know that developers generally poo poo this sort of smoke-and-mirrors approach to application development, because things are remarkably easy at first, then anything that takes you off of the “rails” becomes tremendously difficult, and more difficult than just developing it from scratch in the first place. Enter Ruby on Rails and the fully object-oriented approach. This was the first generalized application framework that I have researched that appears to be competitive with my own. My own system is a dramatically limited (MVC) Model-View-Controller model that doesn’t use templates, and has no object-oriented overriding of components built for previous apps. That’s what Ruby on Rails brought to the picture, plus their scaffold concept. Whereas my system has default generalized behavior that get overridden by adding logic and activating keywords in the config file, ROR has you build alternative Models, Views and Controllers, until you’ve swapped out all the default behavior in a truly object oriented way. The result being reusable libraries of your own personal generalized system built on top of ROR. Scaffolding is the perfect visual model for what’s going on here, and really plays off of Ruby’s fully object-oriented approach.

So, my question is where do I go in my next step? Do I abandon my system for ROR? I clearly want to cut my ties to VBScript/ASP. But this is hard to do, because VBScript under ASP is just so darn easy. As someone who repeatedly tried to cut my teeth on Java, I always newly appreciate VBScript’s rapidness, simplicity of syntax, and tight spiral development/deployment cycle. I’ve literally been able to advance the overall system under peoples’ noses without a single server stop/restart. People argue for JSP or ASP.NET to solve these problems. I’ve tried ASP.NET, and feel my generalized system would be totally possible and benefit from the vastly larger system/component library (similar to Java), but everything else that ASP.NET brought to the table, such as DataGrids and ViewState were much more of a hindrance than a benefit. To make the system my way, I would have to write under ASP.NET as if I was under ASP Classic. I would get a faster, native SQL Reader controlled by auto-compiled code. And if I took that approach with my exhaustively documented project also found on this website, I think it would have been a much greater success. Instead, I went on a scavenger hunt to figure out how to use the most appropriate pre-built ASP.NET component, then went on to wrestle it like an alligator to get the behavior I needed. It is much easier to build my next system on a reduced set of tools that don’t (overly) marry me to any particular technology or pre-existing framework. Yes, that answers it. I want to build my own next generalized system. But I want my system to play off of ROR, benefit from it, co-exist with it, and live separate from it, all as needed. I want the best of all worlds in the next iteration of my system.

How does one do this? How do you build a generalized application framework without marrying yourself to a particular technology? Can the back-end pieces be built in different languages and still communicate with each other? Can you use Java where it’s most appropriate, Ruby where it’s most appropriate, and the same with VBScript? Can you do it without over-complexifying it? Can it have beauty and elegance, few lines of code, and be easy to update, manage, customize, and be implicitly documented? Can it sit on top of or along-side with existing frameworks, providing alternative modes of operation? Can it provide quick prototyping, then become the true deployed application because the prototype is so fully complete? Can it be done so that it can be customized without limits, even though the generalized framework provided instant usability? Can it scale without limits, supporting millions of records and tens-of-thousands of simultaneous users? Without a server farm or load-balancing? I would also like it to be open-source based, so it can be a company’s business framework without having to pay anything to any vendors, except for hardware, increasing consultancy profits. But when it needs to connect to Oracle or SQL Server, it certainly should be able to. These are the questions on my mind when developing the next iteration of my generalized system. And I’m ready to embark on the project.