Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Writing Nearly Codeless Apps: Part 1

By David Ziffer,

How to win the Indy 500

Quick .. who won the Indianapolis 500 this year? Andretti? Castroneves? Penske?

Actually, the real winner was the Honda Motor Company. Since 2006 Honda has made all the engines in all 33 cars of every Indy race, so no matter who wins, Honda wins. In 1994 Honda was new to Indy racing, so it took Honda just 12 years to eliminate all competitors. Even more interesting is the fact that prior to Honda's arrival, Indy drivers had a greater chance of dropping out due to engine failure than from crashing. Now the odds of engine failure are approximately zero, which means that if you didn't finish, you probably crashed.

Honda won the Indy using the same technique that it's been using to eviscerate the American auto industry over the past five decades ... it converted auto manufacture from art to science by eliminating variation from its manufacturing process. Honda auto parts are far more uniform than those of most competitors, giving Honda lower overall costs of manufacture, reduced need for testing, and staggeringly higher reliability.

How to lose at software development

The software industry today resembles pre-assembly-line car manufacture. Small groups of craftsmen build apps pretty much any way they wish, often with little or no systematic guiding strategy. With time and ever-changing staff, applications become more complicated and unreliable. Employers and consumers pay the price in the form of high development and maintenance costs.

In a typical development the schema design is done by a database guy who is obsessed with micro-optimization of individual tables. He fusses over minimizing table size and deciding things like which tables should get synthetic keys or status fields. The result is a hodgepodge of table designs, all within the same app.

Then we bring in the app guy to design the data layer. He's already stuck with an inconsistent schema, and he's so accustomed to this that he doesn't realize that it's a bad idea. The app guy must now contemplate the individual design of each table when writing the code to access it. Does it have status fields? Maybe. This one has a synthetic key, that one has a business key, and a third one has no primary key at all. So he creates a ton of hand-written custom code, all of which must be maintained throughout the life of the project. Or he decides to use an ORM such as Hibernate, which has a 900-page book for a manual and requires the app guy to supply perhaps thousands of lines of "code" written in non-type-checked XML.

At the end of the day, neither the database guy nor the app guy realizes the opportunities that were missed. Could we have built or used a tiny, efficient ORM if all the tables had had the same sort of primary key? Could we have audited the entire app if every table had status fields? Would the long-term cost of maintaining this app be dramatically reduced if there were consistency throughout? Unfortunately nobody gets paid to ask or answer these questions so nobody does.

The automotive craftsmen who micro-optimized every screw in every panel of every car they built thought they were doing everyone a big favor. To suggest that there was another way - that cars could be fantastically improved and cost-reduced through consistent systemic design - was laughable. Only after Henry Ford decimated his competitors did such ideas seem self-evident.

A coming revolution?

The world of software development will change radically once somebody starts building applications in a drastically more consistent way. We can and must have a revolution similar to the assembly line in auto manufacture.

In this article series I suggest a specific solution - one that you can start using immediately upon your next new software project, hopefully producing immediate results. The objective here is to produce small to medium database-based applications in which the vast majority of code is already written or generated for you, so that  your only worry is to actually solve the business problem at hand. But these benefits will come at a price. For perhaps the first time ever, you'll be required to dramatically reduce the variations in the way you design your schema and software. The main point of this approach is not merely the use of libraries and code generators (which you've no doubt seen before) but gaining extraordinary additional benefits by placing extraordinary restrictions on design.

Sounds unpalatable? Probably most of Henry Ford's craftsmen didn't like the assembly line either. The reward? If you stick with the series, I will ultimately provide you with both the methodology and all the code you need to make yourself potentially many times more efficient than you are today.

Rapid Application Prototype

We avoid reinventing the wheel by starting with an application prototype that already defines the structure of essentially any database-based application. The Rapid Application Prototype (RAP) uses a four-tier model:

RAP Four-Tier Model

RAP comes with a database preprocessor that helps you generate databases where every table has the same primary key design and the same set of status fields:

RAP Database Preprocessor

RAP also has a Database Generator that automatically creates all the CRUD code for both your database and your data layer:

RAP Database Generator

RAP also has an extraordinarily simple ORM that requires almost no user manual. And finally, RAP comes with templates for designing your Business Rules and User Interfaces for a high degree of consistency and a minimum of code.

Get started by downloading and running RAP

To run the RAP demo, which is the basis of this entire article series, you will need the following:

  • Visual Studio 2008 or later
  • .NET 3.5 or later
  • and SQL Server 2005 or 2005 Express or later
  • Microsoft Word 2003 or later (to read the instructions that come with the download)

That's all! Start by downloading the Rapid Application Prototype (RAP). Follow the downloading instructions at the link. The download itself contains an Instructions document which will guide you through the steps. You'll need about a half an hour to go through the whole thing.

You can walk through the entire demo yourself without reading any further articles. However if you want to really get into a discussion of how this package works and what it can do for you, look out for the next article in this series.

The Series

This is part of a series that examines the RAP application development system and a philosophy that believes in more standardization for both our database development and application organization.

  1. Part 1 - An Introduction
  2. Part 2- Database Design
  3. Part 3 - Auditing
  4. Part 4 - Insert/Update/Delete Routines
  5. Part 5 - Fetch Routines

Total article views: 18243 | Views in the last 30 days: 1
 
Related Articles
FORUM

Database Design for Blog application

Database Design for Blog application

FORUM

Database Design Help

database design help schema

FORUM

Database design

Very Large database design

ARTICLE

Database Design and Reference Tables

Whether you are building SQL Server 2000 applications or getting ready for the new features in SQL S...

FORUM

A database design question

A database design question

Tags
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones