MSDN Magazine - March 2009 - (Page 67) SharePoint Web Application External Applications SharePoint Web Services Other SharePoint Web Applications Custom Components Web Part ASP.NET Form Web Control SharePoint Business Data Catalog External LOB Applications/Services External Web Services, .NET Framework, Win32 API, Others SharePoint Object Model Figure 1 SharePoint System Interaction Model “Getting References to Sites, Web Applications, and other Key Objects” (msdn.microsoft.com/library/ms468609.aspx) and “Best Practices: Using Disposable Windows SharePoint Services Objects” (msdn.microsoft.com/library/aa973248.aspx). From the perspective of the SharePoint object model, a SharePoint Web application is an important security boundary. Typically, you should not use the SharePoint object model for interactions between SharePoint Web applications. See “Security Programming in SharePoint ” (msdn.microsoft.com/magazine/cc163287) for information about other important SharePoint security topics. When making calls between SharePoint Web applications and between SharePoint and external applications, such as an Office client application, use the SharePoint Web service integration layer. This is a good approach when attempting off-server development tasks in Visual Studio. See the “Develop Solutions OffServer” section for details. To interact with other systems, making calls to external Web services is the most common approach, but it is not always the best approach. Some alternatives might be easier to implement, and they might also have the benefit of being significantly faster—for example, making calls to LDAP stores via the Microsoft directory services programming framework or making calls to Project Server via ADO.NET to the Project Server Reporting database rather than via the Project Server Interface (PSI) Web services layer. When the data source is a Web service or database, consider using the Business Data Catalog (BDC). For more information, see the next section in this article, “Take Advantage of Native SharePoint Capabilities.” Microsoft is very clear in its documentation that you should not make calls directly to the SharePoint content and configuration databases. Even so, some applications are using this approach. Whether performance is the argument for this access technique or simply a lack of knowledge about the SharePoint framework, there are safer approaches. The bottom line is that Microsoft can change the underlying schema in these databases, and there can be more than one content database per Web application. Therefore, seemingly benign direct query operations can lead to brittle solutions. Instead, take advantage of the other approaches outlined in this article or develop a different strategy that avoids suboptimal solutions that compromise the integrity of your SharePoint implementations. msdnmagazine.com 2. Take Advantage of Native SharePoint Capabilities Two situations can lead development teams away from taking full advantage of the native capabilities in SharePoint. First, because SharePoint is such an expansive platform, you might find it easier to build custom solutions rather than spend time to understand what SharePoint provides without custom coding. Second, business owners tend to create detailed requirements, wireframes, and application behaviors that leave you with little flexibility when it comes to using out-of-the-box (OOB) capabilities. But embracing what the SharePoint platform provides often pays dividends, even if the resulting deliverable deviates slightly from the original requirements. The keys to gaining this advantage are for the development team to thoroughly understand the technology and, more importantly, to clearly communicate the value and tradeoffs of a particular implementation to the business owner. Acquiring a solid understanding of the strengths and weaknesses of SharePoint is easier said than done. Both WSS and MOSS include SDKs that contain technical documentation, walkthroughs, code samples, and best practices for programming solutions in SharePoint. Also, when information is hard to find, you can use .NET Reflector to look inside some of the core SharePoint assemblies. Figure 2 shows the members of the PeopleQueryControl class in the Microsoft.SharePoint assembly, including the IssueQuery method. The PeopleEditor control (aka People Picker) delegates responsibility for querying SharePoint’s identity store to PeopleQueryControl and lets you override the IssueQuery method to modify the default implementation. As you can see in the figure, .NET Reflector gives you an inside look into how the components interact. Equipped with knowledge about the capabilities of the platform, you need to articulate the benefits of a particular implementation to the stakeholders in a way that underscores the value of their investment in the technology. It’s especially important with a platform the size of SharePoint not to get hung up early about implementation details but to help the client learn what is possible by releasing early and iterating often. Be sure that your client is familiar with the features of the product by putting in place an effective feedback mechanism that keeps them engaged throughout the entire software development life cycle (SDLC). Imagine a discussion about displaying a large selection list of entities to a user. You can implement this capability in many ways, such as with the ASP.NET DropDownList control, the GridView March 2009 67 http://msdn.microsoft.com/library/ms468609.aspx http://msdn.microsoft.com/library/aa973248.aspx http://msdn.microsoft.com/magazine/cc163287 http://www.msdnmagazine.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.