When does one use Web Parts vs. Full blown ASP.NET application in SharePoint?

Question

I'm still struggling with this question as I'm trying to get up to speed with SharePoint, coming from ASP.NET Web Forms. We're looking to use SharePoint exclusively for several reasons; one of the main selling points is to consolidate our development efforts. So for example, today we have several one-off websites with anywhere from 1-5 pages (smallish) on several servers, IIS installs, etc. and seem to be a bit fragmented.

Let's say I have a requirement for a smallish site (1-5) pages. What is the SharePoint way to handle this situation? Do I create several Web Parts, then create the pages in SharePoint and plug them in or do I simply create an ASP.NET Web Forms application and provide a link within SharePoint to it?

Thanks!

Update

I'm going with neither. Based on feedback and additional research it seems that Application pages are what I'm looking for. Here's a good article: http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx

Nisan

Answer 1

What kind of user experience are you looking for? Sometimes it makes sense to have a static page, and sometimes it's much better to allow users the ability to move things around and create their own page. Creating a web part isn't too bad, but I saw somewhere that you are in a time crunch, it might take you a little while to get over the initial learning hump.

It's tough for me to estimate the learning curve because Visual Studio 2010 does make things a lot easier to do than anything that was available when I was new to SharePoint.

Crain

I guess I'm not too worried about the learning curve. I have researched Web Parts for the last few weeks and I don't think it will be too bad. I think my problem is that I don't know if that's the SharePoint way to get it done? So say this project has 5 ASP.NET pages. That could equal 10 Web Parts. Is that the purpose of the Web Parts or are they for more focused development like a calendars, announcements, etc. I'm just not sure if Web Parts are supposed to be used in this way. That is my question and main concern. Thanks. – Nisan

We try to keep most web parts fairly small in scope. Most of our web parts do one or two things and wouldn't really make good stand alone pages. That's not to say that you can't put a whole page worth of features and functionality into a web part, but I think I would tend to keep them smaller. – Crain

Yeah, sorry, I didn't mean I would try to fit a page into one web part. For example, say I have an ASP.NET web page. That page has a form to enter a new person and grid to view and search. Now if I do it the SharePoint way, I would create 2 web parts - Data Entry Person & View Person. And I would go on like this converting my ASP.NET application to SharePoint. Do you see anything wrong with this method? Thanks. – Nisan

Answer 2

You use SharePoint web parts when you want non-technical users to be able to compose pages through the SharePoint UI - creating new pages in a site, selecting which parts they want for the page, configuring them, and arranging them on the page. They can use audience targeting to only show the desired web parts to certain users.

You get all of that pretty much out of the box with SharePoint. Even if you don't need all of it right away, it's not much more effort than building normal ASP.NET applications - except getting over the initial learning curve.

Houseroom

Answer 3

Don't create an asp.net web application to interact with Sharepoint too quickly, there is much out of the box that you can accomplich with sharepoint. If that is not enough you can easily program Sharepoint 2010. You can create Application pages that are equivalent to ASP.NET web forms. Look into that first before creating 2 disperate systems.

What are the pages supposed to do?

Zaller

It's a customized database. It has people, locations, etc. Many different business rules. – Nisan

I should say that I don't think an out of the box solution works here. I'm on a time crunch so I have to try and do my best to leverage my ASP.NET skills for this first project and learn as I go. So do I create this project with several Web Parts or use a standard ASP.NET application? – Nisan

We did a "customised database solution" with sharepoint application pages, connected to a SQL Server (legacy) database. As easy as standard asp.net once you have the hang of it; and integrated – Zaller

Yeah, that's the way I'm going - application pages for custom solutions. Now I just need to research security since they're open to all sites. – Nisan

Answer 4

Here's what we did... we moved all our existing applications on to a dedicated application site. The idea is that this will enable us to roll out SharePoint faster. We developed a custom Web Part with security-trimmed links to all our department apps on the new application site. Only other deployed solution was for customizations.

The idea is that we can move forward and port existing application over only if there is a real reason to do so. All new collaboration-based apps can be developed on SharePoint from scratch as needed.

UPDATE

You could create application pages but familiarize yourself with the difference between application pages and site pages:

http://blogs.msdn.com/b/kaevans/archive/2010/06/28/creating-a-sharepoint-site-page-with-code-behind-using-visual-studio-2010.aspx

Solomonsolon

If time was not a concern, in your professional opinion, do you believe these applications would be best created with Web Parts? If I have a 5 page application with several grids, textboxes, buttons, etc...does it make "SharePoint sense" to convert those to individual Web Parts? So then I would have View People Web Part, ViewLocation Web Part, Data Entry People Web Part, etc. – Nisan

I would factor out my ASP.NET apps to a separate site/server and skin the front to match SharePoint if it's a Publishing site - more awkward and perhaps unnecessary if it's plain WSS. – Solomonsolon