/// Wednesday, November 30
KISS and the 80/20
I design with two principles in mind, KISS (keep it simple stupid) and the 80/20 % rule. Ckknight asked a question today in IRC about the data layer using hardcoded SQL. What if you want to switch databases? My reply was something to the effect "if you're not using generic SQL then you'll have to change templates. There's no way to get around it." The Gamba data layer implements the basic DAO design pattern, using SQL queries is by design and may be changed without affecting the rest of the application.
In all my years of development, I've only had to change the backend database once on a production application! Thankfully stored procedures were used and the DBAs did most of the work. Our DAOs worked pretty much as is, except SQL Server returns a dataset whereas Oracle returns a cursor. Most companies simply do not switch out databases because one is better. If something works, maintain it.
On a sidenote, what a mistake switching from MS/SQL Server to Sun/J2EE/Oracle was. No big gains at all. The new CIO had a thing against Microsoft. Funny how we spent literally a million dollars on servers and J2EE/Oracle licenses. Guess which applications are still handling millions of transactions? VB6 MTS components running in a web farm on cheap $5000 Windows servers compared to $30000 Sun boxes. The other is the C# application I architected. This was the application we switched to Oracle to supposedly gain performance. In Oracle's defense, we had to use Microsoft's Oracle drivers. At that time Oracle's driver was still in beta. The moral is no fancy J2EE distributed gumbo. Each core application relied on MSMQ with a 20 or so server farm hiding behind a round-robin TCP-IP dispatcher. KISS at the enterprise level.
Back on topic. Gamba will be flexible, but not to the point where it becomes over-architected, over-engineered, over-OOPsed as I like to say. It will be simple and 80% of what AJAX web developers need will be very easy to do. The other 20% will require the usual manual effort by the developer. What you get is a fast, light framework without the bloat. Features will be added as needed not what I think the future will need. Who knows, AJAX may be gone in a few years when the next big thing hits.