When a software platform opens a door, it closes a window; we trade power for convenience every time we move forward. Of course, I don’t have to spell that out for you if you are a SharePoint developer—you probably got here by being an ASP.NET developer first. You miss being in complete control of the markup, don’t you?
Did you ever really have any such control?
Add to the list of open doors SharePoint Online, the Office365 edition of our favorite collaboration platform to be hosted in Microsoft’s increasingly fluffier cloud. By migrating SharePoint cloud-wise, we gain the convenience of not having to plan, purchase or maintain the considerable server and network hardware required for our farm.
The developer’s price tag hanging from this infrastructural boon is a weighty one, though, at least at first glance. Two particularly glaring constraints for cloud-bound SharePoint installations are the loss of Business Connectivity Services (BCS), and that only Sandboxed Solutions may be deployed.
This effectively prohibits your server-side code’s access to resources outside of the local server, and in most cases outside of the local site collection. While these abilities may be on the fringe of what is currently being taken advantage of by SharePoint developers, someone is bound to cry foul when currently available features are suddenly not.
Long story short, get used to Sandbox solutions – and the new way of programming. Sandbox solutions are pretty damn good. Most of the complaints I have heard around sandbox solutions being too restrictive, are uninformed mechanisms of doing things mired in the ways of 2002.
.. or you could just live in 2002 too.
The last thing any self-respecting developer wants to be accused of is being out of touch, of retreading (insert recent past year here). But is this a fair grenade for Malik to lob, considering the youth of Office365 and even of SharePoint itself? Or is he donning rose-colored glasses in the face of the functionality being lost?2 comments