Persistence pays off, part 1: the server

No application is complete without a means to persist information for later retrieval. Server-side persistence is an important part of a Web-based application.

---

by Michael L. Perry, president and consultant, Mallard Software Designs Inc. Intel Corp.

A few years ago, a television commercial aired locally that depicted a waitress at a seafood restaurant taking orders by memory. She was serving a rather large party, each member of which had one or two special requests. After each order was shouted out, she asserted, "Got it." When asked if she was going to write it down, she replied, "Oh, I'll remember."

As she walked away from the concerned diners, the announcer posed the rhetorical question, "What are the odds?" The point was clear. A message is not truly delivered until it is recorded in a permanent form. Memory is transient. Durable messaging requires persistence.

In this series, we are constructing a practical Web application—a Web-based product that, unlike some now-defunct offerings, people actually want to use. We started with interaction design, which captures the wishes of the users. We then converted those wishes into contracts, and ensured that the implementer of those contracts had the necessary authority. Then we published the central site as a Web service. Now we must guarantee that the message so painstakingly transmitted to the central site is not lost. Now we require persistence.

You can the source code for the Laurel application.

The dangers of designing the database too early
To design the database before now would have been a mistake. I have been on projects on which the database design was performed too early. Once the requirements were on paper, the database programmers drew their ERDs and wrote their stored procedures, not knowing what the middle tier would actually need. The database design had to be redone two or three times during the course of the project. Worse yet, the original database design pushed back on the business logic, leaving artifacts of the poor design in the middle-tier source code.

The solution that I propose, and have been following in this series, is to let all software modeling follow from the user interaction design. The user interaction determines the contracts. The contracts determine the needs of the middle tier. And the middle tier determines the database schema. Later, we will see how it all pushes out through the user interface. We are not building from the top down or from the bottom up; we are building an application from the inside out.

Consider what would have happened had we started the entire development process by designing the Laurel server-side database. We probably would have constructed a table for customers, a table for orders, and a table for memos. There is no way we could marry the needs of our central site to that kind of database.

But now we know what the central site has to do; it acts as a clearinghouse for transactions in an historic model. The database does not need to store the information model, as a premature design would have it do. Based on the needs as we now understand them, let's choose a database and a data access technology and start creating tables and code.

Choose a database and a data access technology
We have several options for persisting data on the server side. Indeed, our choice is not just which database to store our data in, but also which data access technology to use to programmatically access that data. Our choices of data access technology available in the .NET Framework include ADO.NET, ADO, OLE DB, and ODBC. Our choices of database systems include offerings from many vendors, most prominent of which are Microsoft and Oracle.