Developers are creative beings, particularly when it comes to solving problems. Their problem-solving skills are what make a developer great, coding a solution around problems to make desired functionality or processes achievable. The trouble with developing on SharePoint is that some approaches are more attractive and some are more problematic. Rather than risk having developers drift into those more problematic areas, I like to identify some general practices to help steer the solutions they develop.
I divide these practices into two lists: developer constraints and developer guidelines.
SharePoint Developer Constraints and Boundaries
I use this list to set expectations with architecture and developer teams on the standards their custom components have to meet. Although I will make exceptions to these rules, I insist on a compelling reason for the exception. I find that establishing these constraints and boundaries for customizations in a SharePoint environment drive long-term sustainability and supportability for the SharePoint service.
- All customizations must package any deployment files and manifests in either a SharePoint solution package or an App for SharePoint package for deployment to the SharePoint farm. The deployment package must include all deployment and configuration instructions for SharePoint to automatically apply, including any Web.config settings or changes.
- No customization may modify or overwrite the core SharePoint product and system files directly, including all ASPX, XML, JavaScript, CSS, and image files.
- All customizations store any data they require by persisting it to a SharePoint database through the SharePoint API or by providing its own dedicated data store.
- No customizations may query the SharePoint databases directly.
- All customizations must only access the file system in a read-only fashion, except for copying a customization’s files and assemblies during its initial deployment.
- No customization may implement its own caching solution and instead must use the SharePoint AppFabric or another persistence strategy available through the SharePoint API.
- All customizations must handle all exceptions gracefully and provide a friendly error message while recording any error details to the log when an error or exception condition exists.
SharePoint Developer Guidelines
I use this list to encourage developers toward the most sustainable development practices in SharePoint where possible, but without the same rigor and enforcement as the previous list. This list more resembles nice-to-have practices that have more discretion depending on the solution.
- Customizations ought to avoid exhausting any SharePoint resources from servers in the SharePoint farm, and instead they should consume a web service to do their “heavy lifting” on another server dedicated to handle the customization’s load.
- Customizations ought to verify a requesting client has any necessary privileges for a particular resource or operation prior to attempting access, and where possible, suppress displaying a feature when a requestor lacks those privileges.
- Customizations ought to impersonate the requesting clients’ credentials for any privileged request and avoid using the SPSecurity.CodeToRunElevated method to minimize any elevated privileges and circumvented security risks.
- Customizations ought to access data in external systems through the Business Connectivity Services by providing definitions for any web services and databases the component needs to integrate with, rather than connecting to a system directly.
- Customizations ought to write tracing and error information to the SharePoint log file and allow a SharePoint administrator to set the verboseness of tracing information it writes.
- Customizations ought to make any user interface elements compatible with SharePoint themes and CSS classes.
- Customizations ought to explicitly specify and assert the minimum .NET Code Access Security permissions an assembly requires to minimize the scope of any potential security vulnerabilities.
- Customizations ought to create and consume dedicated Service Applications, where appropriate, to offload and isolate custom tasks and workflows associated with custom code.
Between these lists, I find that they set reasonable expectations and steer architecture and developer teams in a sustainable direction with how they design and code their solutions. I’m not rigid in enforcing these constraints and guidelines, as there are many valid reasons to make exceptions.
However, I do default to stay within this list unless there is indeed a valid reason for an exception, meaning a business requirement and not a convenience-related shortcut. As such, I use this list to guide me toward those solutions that fall outside items on the lists, guiding me toward conducting an architecture review and reconsidering the implementation design to see if the team has thought through the alternatives.
No comments:
Post a Comment