Q&A

SharePoint Developer Q&A: Vishwas Lele

Visual Studio Magazine spoke with Vishwas Lele, a veteran SharePoint application developer, Microsoft Regional Director and chief technology officer of Applied Information Services, about his thoughts on developing apps for SharePoint 2010.

• By Michael Desmond
• 06/02/2010

Vishwas Lele is a Microsoft Regional Director and chief technology officer of Applied Information Sciences (AIS) a Reston, Virginia-based consultancy that specializes in custom .NET application development. A long-time SharePoint application developer, Lele has been working with the platform since SharePoint Server 2001. We spoke with Lele about his thoughts on the latest version of SharePoint (2010) and what it means for application developers.

How long have you been doing development around and for SharePoint, and what kinds of SharePoint engagements do you specialize in?
Applied Information Sciences (AIS) has been doing SharePoint development since the days of SharePoint 2001, though the amount significantly increased with SharePoint 2007. AIS does a wide variety of SharePoint engagements, from setup and administration support to custom applications including custom Web parts, InfoPath Forms, workflow, Excel Services, custom fields, custom pages, event handlers, Silverlight, custom authentication and custom Web services.

Can you provide some context as to how significant a step forward Microsoft has taken with the combination of SharePoint 2010 and Visual Studio 2010, in terms of effective support for application development for SharePoint?
Visual Studio 2010 promotes SharePoint development to almost equal to ASP.NET development. In Visual Studio 2005/2008, packaging and deployment were a set of steps that were either tedious (even with Visual Studio extensions for Windows SharePoint Services) or required a third party (such as WSP Builder). There was a lot of XML hand crafting and batch files for managing building and deploying. The simple F5-compile/debug experience didn’t really exist. Using User Controls as Web Parts was not intuitive and not the same experience as building User Controls for an ASP.NET application.

With Visual Studio 2010 and SharePoint 2010, the most common SharePoint development tasks are now integrated into the product in a way that is much more user friendly and comprehensive than the old Visual Studio Extensions (and even WSP Builder). Web Parts now have a designer surface with an F5 experience equivalent to User Controls and ASP.NET pages. There is significantly less need to hand-craft as much XML as you used to.

What are some of the biggest developer-centric improvements from VS2008/SharePoint 2007 to VS2010/SharePoint 2010?
Well, in addition to what I just described, one of the biggest improvements for developers is Business Connectivity Services (BCS). Simply having the base capability of BCS in the free SharePoint Foundation version automatically makes it a candidate for solutions that weren’t available before, due to the cost of Enterprise CALs for larger organizations. Add to that the read/write capability and the major improvements to the designer capabilities within SharePoint Designer and Visual Studio 2010, and a whole new class of custom applications can be opened up with BCS.

Are there any areas where the VS/SharePoint update proved disappointing? Or areas specific to SharePoint development that you think Microsoft missed an opportunity to improve?
At this stage, I haven’t identified serious weaknesses or disappointments. I would have liked to have a multi-select BCS Business Data Column to support specific requirements that I could have solved with BCS, but the BCS support is so significantly improved with this release that this is a minor annoyance.

Obviously Business Connectivity Services (BCS) are a critical part of the value of SharePoint 2010. How important is it for prospective SharePoint developers to master it?
We have looked into BCS with a great deal of interest and believe this is one of the major key aspects of SharePoint 2010 and should be considered for many kinds of solutions. The line between storing data in a SharePoint list and in an external data store, most likely a database, is now blurred and you have to have a pretty good grasp of the concepts to determine the right path to go when choosing where to store data. BCS allows for very fast integration of external data and provides functionality out of the box that could save significant development and deployment time under the right circumstances.

What are some of the most common mistakes you see from developers new to SharePoint? And what mistakes might you caution them about with SharePoint 2010? Any other advice for .NET developers looking to do more SharePoint development?
Some of the common mistakes that developers, that are new to SharePoint, run into relate to incorrect application of SharePoint platform elements. For instance:

One, even though the list functionality has been greatly improved through the addition of throttling, multi-column index, lookups, joins, etc., there are situations where a relational database makes most sense. For instance, when there is a need for transactional updates, aggregation of list data and field level security.

Two, event handlers are great for injecting small amounts of custom code into a list behavior. But developers must be careful not to overload the logic inside the event handler. Long running event handlers can degrade end-user experience. If the need is to support a long running operation, workflows may be a better choice.

Three, be careful when choosing between hierarchy of Sites versus a set of SiteCollections as the containers of data. While sites are easier to manage (in terms of navigation and security), SiteCollections offer the flexibility to scale. Additionally, SiteCollections allow security isolation.

Four, be sure to check for leaks using tools such SPDisposeCheck.

Five, be careful when choosing the security scheme. In general, item-level security is more expensive. Additionally, breaking inheritance should be handled with care.

Six, carefully plan how the custom solution will be packaged. Can a sandboxed solution suffice? Or is there is a real need to build a full code solution. A full code solution is needed for more advanced requirements such as a creating a time job. Always start from the solution that requires the least privilege.

Seven, keep an eye on page load times from very early on in the project. Too many times we have encountered pages that work fine on the dev machines but perform miserably in a production setting. Run load and endurance tests early and often.