MOSS vs. traditional ASP.NET

Question

I am in process of evaluating MOSS (SharePoint) and traditional ASP.NET for my client's site. The site will be available to client's partners over the internet. I'm interested in differences between these two approaches from following perspectives:

1. Development perspective. How does development differs? What are pros and cons of both approaches?
2. Performance perspective. Which platform shall deliver better performance?

By now, we know that not much features of MOSS can be used out-of-the-box, and the features will be added using web parts.

Answer 1

The big difference that you need to be aware of is the licencing. To use MOSS over the internet will require an Internet licence. The actual cost depends on what deal you have with MS, but it is a significant cost.

We have found that it is more costly to develop for Sharepoint than ASP.net pages. Especially due to requirements for the development environment and deployment problems.

From a performance perspective it depends on how you program it. With ASP.net you have more control and therefore, should be able to get better performance.

Do not use MOSS unless you are leveraging the functionality that MOSS provides.

Answer 2

I would also strongly discourage using MOSS if you have to do any sort of customization. If it does what you need out of the box, then great, but otherwise you'll quickly burn time and resources trying to dance around it.

Answer 3

I can't tell from your question whether or not you're aware that SharePoint is built on ASP.NET and Windows Workflow Foundation.

The big difference in my mind is that the Development model for SharePoint assumes that you are developing against a server. This is not as big a deal as it used to be, since it's practical for each developer to run Windows Server 2008 in a private VM. Still, there's no "Visual Studio Web Development Server" when SharePoint is involved.

See Sharepoint tools support in Visual Studio from Somasegar's Weblog, especially the many comments (72 at last count).

Answer 4

SharePoint out of the box has a lot of great features you will not be able to duplicate as easily. For instance the Office integration. With SharePoint your client can share documents ( word, excel, etc ) and have them kept under revision control.

You can easily setup individual portals for their clients where they can have discussions, share documents, communicate, etc.

SharePoint is also a content management system. Your client can add/edit/remove content as they wish. With MOSS they get the benefit of publishing workflows as well as being able to roll back their changes/deletes. The publishing workflows could spawn an approval process for the changes. Built in

SharePoint's workflow support is a one of the top benefits. You can create them with SharePoint Designer. SharePoint Designer is free from MS. InfoPath forms + workflows provides some obscene opportunities you will not develop as easily on your own.

SharePoint Designer provides an avenue to develop more advanced solutions than the web interface as well as site branding ( look & feel ).

Best thing is, if you create 1 solution, you can bundle it and deploy it. For instance if you setup 1 client portal, you can bundle it and "copy" it to new client portals.

MOSS is a set of additional functionality that you pay for. It can be expensive. You have to leverage the cost of licensing against the cost for you to duplicate what is already available.

Depending on what your client wants you might not even need Visual Studio. A lot of the work can be done by building solutions with whats already there, which is a lot.

Answer 5

Performance wise, it's a tricky one to answer, as it's very depending upon how your custom solution is developed, what hardware platform you're planning on deploying the solution to, etc. I think most people would agree that, in general, MOSS will be slower than an ASP.NET application written in house, primarily because it's unlikely to be as complex and expansive as MOSS.

That said, it's very easy to deploy MOSS across a network load balanced farm (obviously increasing the licensing costs significantly), and share the load that way, thus getting a pretty significant performance boost over a more traditional ASP.NET app deployed to a standalone server.

As others have said re: development, it's incredibly dependant on what you're actually wanting out of the end solution. As Dr said, it would be a major development effort to reimplement some of the core MOSS features, such as it's Office integration, it's document management, version control and fine grain permissions.

If you feel that you're going to have customise a large chunk of MOSS, then the development effort can be quite involved, especially if you don't have anyone in house familiar with the process. It's a big product, and finding your way around it's innards and API is no small task when first starting out.

I should mention that we've had a lot of clients who have gone into MOSS evaluations thinking that there will be a significant amount of work customising, etc, but not realising that actually, 90% of what they want to achieve can be so with minimum development efforts, it's usually more a lack of understand of all the options available to them within MOSS.

Answer 6

Frankly, I don't understand why people compare SharePoint and ASP.NET as if they were competing products. If you need majority of the features of SharePoint (collaboration, workflow, communities, office integration, document management etc), then it may be worth your while to use SharePoint rather than re-inventing everything.

But if you are developing a classic web application, why bring MOSS into the picture? Unless your clients already have MOSS in place and would rather use it to host their apps. And if your clients are really gung ho about SharePoint, you might want to remind them that SharePoint licensing is very expensive while ASP.NET is free!

Part of the curse and blessing of SharePoint is it's ability to be infinitely customized. Most of the features of SharePoint can either be used as-is, customized with SharePoint Designer or replaced entirely by writing your own C# code. This is a blessing because it means SharePoint is infinitely customizable. It's a curse because customizing it can be a royal pain.

Answer 7

That last comment "Do not use MOSS unless you are leveraging the functionality that MOSS provides" by Shiraz Bhaiji hits it on the money.

And I'll even expand on that. Do not use MOSS unless someone in your organization is going to force everyone in the organization to use the MOSS. Because if people aren't forced to learn how to use it and change their ways, you're wasting time and money by migrating to it. Most places I've seen, people continue to use their file shares, and email (Exchange) to share and collaborate with. They never end up using their Sharepoint. I don't know how common that is, however, if you suspect that'll be the case with your organization you should give this aspect more concern.

Answer 8

One of the biggest parts and focuses of MOSS and WSS is "Collaboration" and ECM (Enterprise Content Management). If your clients/partners can utilize these features sharepoint would be a success.

In addition, since MOSS is part of the office 2007 system, it is fully integrated with all office programs and using Exel Services and Infopath Form Services, your users would be able to enjoy web-based Excel and forms without having to install them.

Answer 9

I have written a blog entry which compares the traditional ASP.net and the SharePoint apps. You can see that here:

http://manish-sharepoint.blogspot.com/2008/05/comparing-sharepoint-server-with-aspnet.html

HTH