Common business-related SharePoint development and maintenance Solutions

This article describes some of my thoughts and feasible solutions on business-related development/maintenance in SharePoint.

1. business-related SharePoint application Overview

Generally, SharePoint is used as an enterprise-level KM Portal. When SPS are only used as the KM, they are embedded into the AD personnel management, based on subarea, subsite, list, document library, bbs and other built-in components can be naturally mapped to people, organizational structures, resources, discussions, and so on in enterprise reality. However, in reality, there are also a number of non-KM application systems that are developed based on the SPS platform. In such systems, many business-related logics are inevitably involved, so that the built-in components in SPS are insufficient to handle these additional business logic, what solutions can be used for secondary development at this time?

2. SharePoint Secondary Development Solution

2.1 JavaScript + Custom Data View + SPS WebService

First of all, if the business logic is relatively simple, especially when the data processing and the look & feel of reality and operation are not very complex, and do not mind exposing the business logic on the client, you can use FrontPage to customize the pages in the SPS and the Web Servise provided by Custom Data View and SPS as the Data read and write interfaces. In addition, you can use JavaScript to process Data and customize the display interface, generally, the requirements can be met.

The advantage of this solution is that it does not use any external resources and can be developed, deployed, and maintained online, which is also very convenient for packaging and migration. Therefore, it is generally a relatively recommended solution.

2.2 External Web Service Site

If the business is more complex, especially the data processing capability and security requirements are higher (do not want to expose the business rules to the Client), then compared with solution 2.1, A simple method is to move the Service processing part to the server. One solution is to create an additional Web Service site dedicated to processing such services, and communicates with SPS through the Web Service interface.

This solution adds the burden of developing and maintaining an additional independent Web Service site, but it can obtain the vast majority of the 2.1 Benefits and obtain stronger data processing capabilities and security. Of course, this additional site must not be based on the. NET Framework, but can also be deployed on any remote server.

2.3 External Web Application Site

Solution 2.2 can solve 2.1 of the security issues of "exposing business logic on the client", but cannot solve the problem of "providing complex Display Interfaces and input verification, this solution is to transfer the capability of "providing complex Display Interfaces and input verification" to an external Web Application and embed it into the original SPS site. Application and SPS communicate through SPS Web Service.

However, although this solution can solve the problem of "providing complex Display Interfaces and input verification", it may cause some maintenance problems, the main issue is the consistency between the list of the SPS site and the external site, because the list columns in the SPS can be customized freely. However, if the business and reality depend on an external site, this kind of customization is greatly limited, because the external site will no longer be able to determine whether some resources it is dealing with are still consistent with the design. However, in any case, as long as the customization is properly standardized, this is also a feasible solution.

2.4 Custom Web Part

Seeing the three solutions above, many people may wonder why they don't talk about Web parts. In the development of SPS, Web parts seem to be in a very embarrassing situation. Although it has powerful functions, theoretically custom Web parts can process any complicated business logic and display effect.

However, in actual development, it is often the last one or two of the solutions to be considered. The reason is that the most important thing is that the deployment of Custom Web parts is troublesome, and it takes a long time to get started, it may affect the operation of other parts of the entire site. A small error may cause the whole page to crash. In addition, many errors are often not detected during design, and security and operation permissions are also a big problem, in short, it is really easy to list the shortcomings, because there are many. In addition, it is not conducive to maintenance. If you want to extend additional functions for existing systems or modify existing errors, you will be stuck in the quarary of deployment and adjustment again and again. Therefore, the Web Part method is often considered only when the above solution cannot solve the problem. Of course, from another perspective, if the deployment and maintenance costs are relatively low, or the business logic and display interface are extremely complex, the Custom Web Part solution may also be given priority.

3. Summary

To sum up, according to the complexity of the business needs, the solution from 2.1 to 2.4 should be able to meet the vast majority of the needs. If conditions permit, in general, we should try our best to select the top scheme.

Of course, you must analyze specific issues in any application scenario. This article only provides some incomplete suggestions, developers' experience and capabilities, and existing reusable resources, you can choose either solution or another solution!

// End the article