Design style for OData in datajs

The datajs source code is out there for the world to see. Today I wanted to share a bit about what style we use and why we decided upon it.

After years of writing for the .NET framework, one of my first impulses is to start thinking in terms of objects. However there are a few variations on how you deal with objects in JavaScript and what object-oriented features you decide to leverage. There are no shortage of writings on emulating classical inheritance, supporting C++-style mix-ins, modeling interfaces, using prototypal inheritance, and how to control visibility of variables and object members.

If you found any of the above perplexing, you could do worse than start with Douglas Crockford's site.

To keep in line with our principles, we decided that we didn't want to introduce more complexity than was warranted. The OData support currently implemented in datajs is essentially a communication layer: requests with packets of data go in, and requests with packets of data come out. There are really very few things that need to be modeled as objects, and those are all internal details or advanced extensibility points (like customizing the httpClient layer).

As such, we decided to simply have a good definition for what the packets of data should look like (entries, feeds, etc.), modeled largely after the JSON format that goes on the wire (so it's easy to correlate what Fiddler for example shows with what you have in memory). Then there are a couple of functions to read and write them, and off you go - the entire protocol is now accessible to you in all its goodness, with a uniform, simple interface, and a minimal number of concepts to learn.

As we take on additional areas in the future, we may introduce more object-oriented features, but rest assured that whenever possible, we'd rather design out complexity rather than introduce it and having to solve it.

Enjoy!