次の方法で共有

Customizing SharePoint–Most Times the Quickest Way is Not Always the Best Way

  • [アーティクル]

With many customers and partners migrating to SharePoint 2010, one of the topics I get asked about regularly is making “safe” customizations to SharePoint and thinking about upgrades and migrations – both now and in the future. While the answer is often “it depends” there are some general guidelines that I offer:

  1. Do NOT customize the SharePoint database schema. This can cause issues with SharePoint now and upgrade challenges in the future with patches and releases.
  2. Do NOT go directly at the SharePoint database tables to read or write data. Use the public web services and APIs that SharePoint provides to do this. This helps make sure that you are letting SharePoint do its thing and apply the appropriate logic, business rules, etc. It also helps protect you from future schema changes.
  3. Do NOT change SharePoint system files. Just because you can, generally doesn’t mean you should. I’ve heard many horror stories from customers that have had people do a “quick” change by modifying SharePoint system files and then find that these changes are either broken or overwritten when applying patches, service packs and upgrades.
  4. Do NOT randomly start making changes to SharePoint in Internet Information Services (IIS). Yes, SharePoint is an ASP.NET application and some things can be changed outside of SharePoint. However, most changes are best done via SharePoint Central Administration.

As for making changes to SharePoint itself, as I’ve mentioned in my SharePoint as a development platform and crawl, walk, run posts and talks here are some general strategies to help speed development, testing and ease future maintenance of SharePoint solutions:

  1. Start with using the out of the box SharePoint site templates, master pages and web parts and making customizations and updates via the browser.
  2. Use SharePoint Designer to create custom master pages, design page layout templates, create Business Connectivity Services (BCS) connections to external systems, build reusable workflows and make more advanced customizations. SharePoint Designer continues to be a free tool and has been significantly improved with the 2010 release.
  3. Consider building Composite Applications and using some of the advanced SharePoint capabilities like InfoPath forms services, Access Services and Visio Services using the Microsoft Office client applications as design and publishing tools.
  4. If none of the above options work for you, and you really need to crank out some custom code for your solution, build them in a supported way using Visual Studio and the best practices, integration and design patterns highlighted on MSDN.

Comments

  • Anonymous
    January 01, 2003
    I fully agree Chris. With Visual Studio 2010, SharePoint 2010 development is now a 1st class citizen. I expect many ASP.NET developers to be very excited about the improvements here.

  • Anonymous
    June 30, 2010
    Very solid. Let me also add this - if you're a "power customizer" but have been afraid of Visual Studio - get over it!  Visual Studio 2010 is easier than ever for building and deploying customizations - simple data bound web parts or customized list templates in less than 15 minutes, as manageable code.  VS2010 is your friend.

  • Anonymous
    February 24, 2014
    http://itsoutlook.wordpress.com/2012/05/22/to-much-customization-in-sharepoint-injurious-to-health/