In the previous sections we reviewed the capabilities along with some advantages and disadvantages of each of the development and customization paths. Choosing the right path for your solution requires that you consider your environment and the requirements of the solution.
There are a number of environment variables to consider that have an immediate impact on your development options.
Since cloud based SharePoint environments do not support farm solutions, sandboxed solutions and client-side code represent the sole methods for creating customizations. Even if you are not in the cloud today, it would be a good idea to consider if that is a possibility in the next few years. If you have a simple solution that can be accommodated with either sandboxed solutions or client-side code, then it might be a good idea to cloud proof your customizations to reduce the hassle and rework later.
In many organizations there is either governance or change management policies that can define capabilities or potentially rule out some of the development options. That should be given strong consideration before choosing a development path. In cases where there is a robust change management policy for anything deployed to the server, it can sometimes take weeks for changes to be deployed to the server after they have been developed and properly tested. Those constraints can make it very difficult to provide updates or respond to change, so in those cases it can be very important to choose a path where you can be responsive and deploy quickly.
It is also important to consider how your teams are organized and who has what access to the SharePoint system's Central Administration. In some organizations access is tightly controlled and given to a small set of administrators who do not create customizations. In other organizations the administrators are also the developers and have access to both create and deploy solutions as needed.
When making a choice on the development path, it is also important to consider how or where the solution will be used. The approach may be completely different when developing a reusable solution expected to be deployed on sites throughout multiple farms, when compared to the approach for a simple solution intended to be used on only one site collection.
For the reusable solution it will be critical that updates be deployed centrally with a solution package update built within Visual Studio, but for a single use customization it may be acceptable to manually apply it where it is needed using either browser customizations, through SharePoint Designer, or with InfoPath Designer in the case of forms development.
Another example is when working on customizations to MasterPages and CSS. While this can effectively be applied to a single site collection using SharePoint Designer, it would be extremely difficult to try and maintain it manually across 1,000 site collections throughout the organization. Using Visual Studio to package and deploy the solutions will not only make the solution more maintainable, but it also gives the developer the option of including additional code that can automate additional tasks through the use of Feature Receivers and Event Receivers. Within the context of the existing example, this can include automatically setting the MasterPage when the feature is activated as well as when any new sites are provisioned.
When you are architecting or designing business solutions it is important to consider the overall scalability requirements. Consider how many users will be using the system, and what the overall performance requirements are. Designing a feature to support ten concurrent users is much different than designing a feature for five hundred concurrent users. Also, in cases of content roll-up as the number of data sources or sites increase the performance of the feature will change substantially. In some cases even commercially available roll-up features fail completely when trying to aggregate content from more than one hundred sites.
Strongly typed server-side code, running in a capable environment, will always perform better than weakly typed client-side code. In addition to actual code execution, another downsides of client-side development is that since everything is running on the client, all of the content needs to be downloaded to the client. That means there is potentially extra content being transferred, but not displayed. In addition, client-side development does not have the ability to cache data the way server-side development does.
For simple solutions or in small environments, the scalability of the solution may not be a real concern and far less important than the value provided by the easy deployment options. For more complex or heavily used solutions, the scalability of server-side development should be given serious consideration.
Application lifecycle management (ALM) is a software development process that supports the combined management of all application requirements, source, build, and testing processes. For organizations with a focus on ALM, there may be a requirement to include all formal projects and development in the ALM tool or environment such as Team Foundation Server (TFS). Development tools like Visual Studio provide full integration with standard ALM tools including TFS which means that solutions created in Visual Studio, using the Server OM will work transparently with ALM processes.
For client-side development or anything done in SharePoint Designer there is currently no support for ALM so things are not so easy. To support ALM with the other SharePoint development tools the developer will need to manually keep source files synchronized through a manual copy and paste process. This can make managing larger, more complex project using these tools and technologies a lot more tedious. In cases where you have a lot of code or a mixture of client and server code you can also consider deploying the client-side scripts to the server as part of a solution package, but in doing so you lose the flexibility and convenience of end user deployed customizations.