Which parts of Sharepoint do I need to understand to build a publicly facing website?

Question

I am building a publicly facing website that does the following. Users log in. And then view a list of their customers. They click on a customer to view their past purchases, order them, change them etc. This is not a shopping site by the way. It is a simple look up tool.

Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.

Typically I would build this using a standard ASP.NET MVC website. However the client says they want to use Sharepoint.

As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html

Here are my questions:

• Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?

• If I had to use it, would I need WSS or MOSS?

• If I had to use it, would I be right in saying the site would consist of :

• List item

  a) Web Parts

  b) And a custom site layout. How do I create one of these?

Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start

Answer 1

1. True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?

2. WSS is enough

3. You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.

Answer 2

1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:

• It costs thousands of dollars to license SharePoint for use on the open Internet
• SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
• SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)

SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.

2.) I believe MOSS would be required for the Internet license (as in the link above).

3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.

Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.

Answer 3

You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.

You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.

You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.

To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.

Answer 4

Hi Petras

1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:

• They can add Content Editor WebParts to pages where they can add descriptions, and messages
• They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
• The functionality you develop can be reused on their intranet
• Any future small "web apps" can be included in the same site
• ...

So all in all unless you have a better framework to use then use SharePoint

2) WSS is all you need for now

3) Your main deliverable for now would be:

• a feature with some Site Pages and a few Web Parts
• a feature with a custom masterpage and corresponding css