开发者

What are the pros and cons of developing a SharePoint component versus a standalone app?

A client wants us to develop a Picture Library system for them. The requirements are pretty typical - need to add pictu开发者_运维问答res, tag them with metadata, store different sized versions and so on.

The client is keen on it being developed as a component which plugs into their existing SharePoint system. However, my feeling is that we would be better served building a standalone app - that way we don't have to shoehorn it into a SharePoint page and muck about integrating with SharePoint's APIs.

I am trying to look at this objectively and would welcome any arguments either way that people have.


Using an existing framework like Sharepoint imposes a lot of constraints on the design which makes the software architecture more uniform.

It does require some work on the part of the developer, because the developer does have to understand the API architecture and API's, etc.

However, developing a standalone application is the way that business's software architecture becomes a mix of 200 applications, using 20 different languages/architectures/platforms, half of which were developed by people no longer there - in short, a mess.

Sharepoint is documented, and will be supported probably long after you leave the company. Can you guarantee support for the application that you develop for as long as Microsoft will support Sharepoint?


You should do a cost/benefit analysis of integrating with SharePoint. You have listed some cons for integrating with SharePoint. Here are some pros.

  1. Widely adopted platform.
  2. Existing functionality to store/retreive/update images to data store.
  3. Existing functionality to tag images.
  4. Existing functionality to group several images together and treat as one virtual document (if using SharePoint 2010).


Keep in mind that you can integrate any custom ASP.NET page/application in Sharepoint so you can approach development like a standalone app. Your client wishes might include synchronization with Sharepoint's own picture library functionality and in that case you'll have to work with it's API.


It seems with SharePoint you are already done because it can more or less do what you describe already. What requirements do you have that cannot be met by OOB SharePoint?

I've used picture libraries for something similar before. While they have their quirks you do get a lot 'for free' like a UI, bulk uploading, metadata and 2 alternate sizes rendered.. My biggest gripe is they don't support the datagrid view so I cannot edit list metadata en masse like you can with other list types.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜