One of the things about transitioning from traditional web development to developing in the cloud is that you tend to need to “unlearn” as much stuff as you need to learn. One of those first things I had to unlearn was the work required to talk between the database tier and the application server tier. Most applications these days are very data-intensive, yet there’s this thick line that gets drawn between the database and the rest of the application. The database is modeled around tables and columns whereas the application logic is modeled around objects and properties. Results from the database are a collection of flat rows, but results from application logic are objects held together by sequential and hierarchical references to each other. Modifying an application object’s data is done by setting a property, whereas modifying a database row involves creating and issuing a text-based command (i.e. UPDATE statement) sent to the database. And so an entire category of techniques and technologies was born to solve the translation problem between the database tier and the application tier. Writing these mapping layers is neither fun nor particularly value-added. Many progressive developers are now using automatic code-generation to spit out thousands of lines of code, but almost always need to get in there and mess with what’s been generated. Not to mention writing a bunch of boring code to efficiently handle database connections.

Now let’s talk about how Force.com handles this. Internal to the Force.com architecture is a database and application server that is subject to all the same issues. However, specific extensions have been made to the application server to handle much of this low-level logic and present you, the developer, with a higher-level, richer way to interact with the database. I want to highlight a few key features around this:

Database Connections
You don’t need to (and in fact, you aren’t able to) create a connection to the database server. Instead when you want to issue a query, the application server will handle the connection internally on your behalf. No connection objects, no server names, usernames and passwords, no worrying about disconnecting.

Object/Relational Mapping
When you execute a query to the Customer table, you don’t get back a “recordset”, you get back a strongly-typed Customer object. Even field types are preserved: if that table has a CreatedDate column defined with a date data type, then your Customer object will have a property called CreatedDate with a date data type. The ability to just run a query and get back an array of application objects is a huge jump in productivity.

Inserts, Updates, and Deletes
While you do use a SQL-like expression (SOQL) to retrieve data from the database, you do not (and actually are not able to) run INSERT, UPDATE, and DELETE SQL statements. Instead, the Apex language has been extended to natively support database operations. To insert a record, you simply create an instance of your strongly-typed object, set it’s properties and say “insert myObject;”. No more concatenating brittle strings to form an INSERT SQL statement. Not only does this save you so much time, it greatly improves the readability of your code.

These items above are just a few of the relevant features, I’d encourage you to explore more on your own. Check out the Database Integration section of Jon’s Introduction to Apex article to see some code examples of this stuff in action.

At the end of the day, unless you feel that you have some true intellectual property in the way you connect to, map to, and integrate with your database today, why would you want to write all this infrastructure yourself? Force.com enables you get right to the core business logic of your application.

Happy "unlearning".