+Blog

Alex Berg

Force.com - Application Platform or Database Platform

For an upcoming blog post, I’m currently doing research on unit testing best practices and techniques as they should apply on the Force.com platform. While doing so, some previously unquestioned beliefs held by me are now being questioned. My question: As a Force.com developer, are we application programmers or are we database programmers?

The question may seem insignificant for most, but it becomes quite important when considering the bigger picture. If we are doing application programming, then we should read existing literature on application programming best practices. If we are doing database programming, however, then we should read database literature and best practices according to database administrators! While the two disciplines are alike in many aspects, they are quite different in others - most notably so.

An application programmer deals with creating algorithms and user interfaces, connecting the user with powerful functionality and a data store in the back-end. A database programmer, on the other hand, deals with such problems as data security/data access, programming logic to ensure data integrity, and adding behavior to database CRUD operations. The most significant difference between the two responsibilities, in my eyes, is the concept of state. Application programmers seek to minimize this application, while database programmers are forced to live with it every day - a database IS state by definition.

Now, taking the Force.com platform back into the discussion, which is it? Is a Force.com developer an application programmer or a database programmer?

To narrow the question, let’s look at the abilities of the platform and its commonly-used functionality, and decide on which side of the fence, application or database, each facility falls. Triggers are clearly database programming, as almost every relational database today has them. Workflow rules are probably database programming, as they are similar to triggers. Apex classes are an object-oriented language construct, and as such should be classified as application programming. Visualforce pages, components, and controller classes are aspects of web/front-end development, which I’ll throw in the application programming category. Validation rules fall on the database programming side of the fence, as they ensure data integrity, a database concern. Users, roles, and profiles and field-level security/object-level security falls under the database programming umbrella.

After breaking it down, it appears that Force.com silently blends the database programming into the application programming. This has increased usability, but for the careless pragmatic programmer, how to best handle these new-found responsibilities may have been overlooked.

With that assertion, I’ll conclude this post. I just wanted to introduce the idea to you. Between now and the next post, I’ll be doing research about unit testing practices for code as it interacts with traditional relational databases to see what ideas and concepts are already being used that can be carried over into Force.com land.

If this post has sparked some thoughts or inspiration, please do leave a comment below. Alternatively, I’ve provided my Twitter and Google+ handles on this page, so feel free to use them.

Posted in: Programming, Salesforce, Software Development