Moving from custom ASP.NET application to Sharepoint Services

Question

Our company has an ASP.NET application for customer information database. The application started small but has grown without proper design. Now a new version of the app should be developed, which basically would mean designing and implementing it from scratch. The company is interested in making use of Microsoft Sharepoint Services in future and it has been suggested to pilot it with this customer database application.

So my questions is:

Is database driven application something WSS is good for? Mostly the app would perform CRUD-operations on the database and also create reports.

Ginkgo

Answer 1

I agree with Greg in that I wouldn't necessarily recommend putting your data in SharePoint lists (this is what Greg may be assuming). But my short answer would be "maybe".

Here's the long answer...

SharePoint runs on ASP.NET so it should accommodate your needs. You would likely be writing ASP.NET web pages that live within SharePoint that access your database or writing web parts that live within SharePoint that access your database.

You could consider the BDC for reading/retrieving data, but that requires MOSS Enterprise and won't provide the CUD part of CRUD. Other tools like CorasWorks DIT may help, but I suspect that custom web parts or pages are the way to go for you.

There are plenty of benefits you can get from SharePoint such as authorization and maybe things like integration of your data with SharePoint list data, provisioning, search, etc. It really depends on the nature of your application as to whether SharePoint will provide much of a benefit.

Detribalize

Thanks for the answer! Custom web parts seem like the answer I am looking for, I'll have to do some research on that. I'd be also interested in hearing comments on how much does developing on Sharepoint differ from traditional ASP.NET. – Ginkgo

Some things are quite the same as ASP.NET and some are different (e.g., deployment if done right). Here's a link that may help get you started: wiki.threewill.com/display/enterprise/… – Detribalize

Answer 2

Short answer: No.

Long answer: Is there any collaboration? Supporting documentation for the data? Workflow? If no, then there really isn't any reason to host it through SharePoint - you won't be gaining much.

Additionally, keep in mind that the SharePoint lists may look like tables, but they aren't - there is no relational aspects of the lists - no joining, no cascading updates/deletes, etc. This may be a problem if data reporting is a big part of your app.

You can store the data externally and have it appear as read-only lists in SharePoint, but you're still jumping through a lot of hoops if you're not using any of the other SharePoint features.

Holloweyed

Answer 3

Kirk beat me to punch and said it better than I would have anyway :)

Another thing to consider is the possiblity of workflows in your process. For example, if you need to start a process when a new contact is added (a follow-up call, etc.), then SharePoint provides a great deal or benefit.

Perhaps a hybrid solution would be appropriate. A custom app for your CRUD and SharePoint integration for the pieces that make sense and provide value.

Building in SP for the sake of using SP probably isn't a good idea.

Disciplinant

Answer 4

We have an ASP.NET application that runs in MOSS 2007. While we barely use any of SharePoint's features, we do get the advantage of SharePoint's security model, navigation webparts (we use CorasWorks), integrated Reporting Services, and workflows. In the very least, SharePoint features are there for us to use someday.

All of our application data is in its own SQL Server database. We don't store anything in the SharePoint content database.

Stlaurent