Curly Code

The title is misleading as what I really mean is developing applications on top of SharePoint without creating a custom database for storage. You might find it strange to see SharePoint this way, because according to Microsoft, SharePoint is about

• Collaboration
• Portals
• Enterprise Search
• Enterprise Content Management
• Business Process and Forms
• Business Intelligence

I’m sure business see it that way as well, or else it won’t be a $800 million business even back in 2007. But as developers, we always see products differently from business users, or even infrastructure folks. As we as a group tend to suffer from NIH. We want to build things that work, not tweaking config settings any day. However, when people in suits come to you and the decision is already made, we’re often left making do with whatever we get. Case in point, in recent months, the pick up rate in SharePoint is really huge. From Singapore to UK, I come across customers demanding SharePoint deployments; and they often lament the lack of SharePoint developers.

Ok, enough about the rise of SharePoint. When we design our application around SharePoint, there are often multiple ways of achieving the same results, with differing amount of effort and user satisfaction.

One thing you will realize is that despite the differences among them, they share an amazing similarity: all of them store the underlying data in a SPList. This is pretty huge on its own. Previous custom ASP.NET development typically requires a separate data access layer (and optionally business logic layer for more complex systems) to be written in stored procedures. Now, with SPList, it’s possible to abstract the data access to SPList API calls.

With the rise of hosted databases like SimpleDB, Datastore API on the one hand, and ORM tools like Entity Framework, Hibernate and Spring on the other, the days of hand cranking select-project-join type of SQL queries seem to be a thing of the past. If you are developing application using non-RDBMS, the idea of using SharePoint lists are storage of data may just seem logical. Sure, the ability of join is not there without complicated CAML queries or nested loops around DataTables, but the fact that you don’t have to deal with the corporate DBAs may just give you a nudge in the right direction.

Just a note of caution, if you do choose SPList as your data store, all lists are stored in the same table in the content database and you will likely run into performance issues. So, your list schema may not map to separate tables as you would normally expect. This is different from the the model provided by SimpleDB or other hosted databases. As a result, this approach is definitely not suitable for complex/transaction-based systems.

What are your thoughts on this topic, readers?