Choosing the Right SharePoint Development Environment

When developing a SharePoint solution, there are many choices of development environments to get the job done, but they are not all equal.

Once you’ve figured out the purpose of the page, how many web-parts are required for that purpose, and what the inputs for each web-part are, only then can you consider which development environment is appropriate according. Imagine the following options as a kind of inverted Maslow’s hierarchy SharePoint development:

1. Native SharePoint. The basic foundation. The primary design goal is to develop single-purpose pages containing 1 web-part developed within the native API. Not only will these be the fastest to prototype, but they most closely model the types of pages the user will be creating themselves once they take own the system. Decision making or filtering logic is present, though rudimentary. Common uses include: displaying custom lists of information. Ex: Text, list display, data entry against existing lists.
2. SharePoint Designer: When the intended design falls outside the bounds of Native SharePoint, SharePoint Designer should be the next choice. This allows for more custom control of what the displayed data will look like, and allows for more detailed data filtering than is possible in native SharePoint. Finally, SharePoint designer allows the incorporation of custom action controls and workflows. Here’s some hints when deciding if
   1. Does the information require a non-uniform display? Summarizing data, changing which columns are displayed, and changing which columns are editable at run-time can all be done within SharePoint designer.
   2. How complex is the data filter? Native SharePoint can filter data on static values or can filter on the logged in user, but other dynamic filter criteria such as date or a query parameter embedded in the url can only be done in SharePoint designer.
3. Workflows: Not so much an entire development option as an addendum. Workflows are like database triggers, and can automate common tasks on data change events, making nice little data-icing to the primary page design. Examples include ‘send an e-mail to the creator whenever the record is edited’ or ‘update a record in list-A whenever list-B is modified’. The Workflows are easily configured within SharePoint Designer, and can quite frequently eliminate the need to spin the task off to a custom web-part. Also please check out Danny Budzinski’s technique for Using workflows to implement list-wide for-looping.
4. Custom Web-parts. If what you need isn’t possible in SharePoint designer, then it’s time to bust out Visual Studio and develop a custom Web-part to handle your task. Like a professional camera, this offers near full control of the graphical representation, math, and validation. Please be aware that like custom PC applications, not all IT administrators are keen on using custom web-parts on their servers. No matter how good your kung-fu is, to the people that have to maintain the system, custom code can introduce an unsafe and/or inefficient element to their server.

I think of custom web-parts akin to cursors in Database development. Very powerful, but if your first design instinct is to use a custom web-part, then either your first instinct or your design is likely wrong. Harsh, but like the scientific method, it’s always worth it to do the due diligence before reinventing the wheel yourself.