Evaluating Sharepoint vs ASP.NET as a development platform

Question

I am evaluating Sharepoint (not MOSS) vs ASP.NET as a development platform for an upcoming solution for our team. We will be developing a solution for broad (we hope) deployment across a variety of environments. I am identifying categories to evaluate pros / cons for each platform choice. I have picked categories that are applicable to our solution requirements and that will affect developer / tester productivity. Can anyone think of any other categories that would be appropriate for a comparision? Can anyone provide any detail on your experiences with the two platforms with regards to any of the categories?

Some other information, we have a short two month time-frame to release something, so we are prioritizing features as we speak. We see Sharepoint as a way to get something out the door quickly while leveraging the UI framework for a basic UI, security, and lists and document libraries for storage.

Development Environment

Developer Productivity

Functional Testability

Developer Testability (unit-testing)

Role Based Security

View-based Security

User Experience

Database - Easy of development with Sharepoint based on the use of lists. However, adding reporting as a requirement makes using lists a hinderance.

Reporting - Sharepoint makes this difficult

Document Repository - Our solution will require multiple document libraries to attach artifacts to solution elements

Packaging

Installation - Sharepoint provides us with easy famr installation via WSP.

Scalability

Extensibility

Complexity

Conceptual Integrity (domain boundaries)

Redundancy/Replication/Backup/Recovery Support

Answer 1

I don't see cost.

Answer 2

Is your solution going to have anything to do with collaboration or web content management? If not, adding SharePoint into the mix is not going to be a great idea.

Using WSS 3.0 as a developement platform instead of ASP.NET would require some serious justification and it is not possible to tell from your limited description of your solution why you would even contemplate that.

On all your measurement aspects, creating developement on the SharePoint platform would add coplexity and therefore cost to any developement effort.

Update

I see Sharepoint security, document libraries, UI framework, and the lack of having to construct and test a DB as great productivty enhancers. Those are Sharepoint features that we can greatly benefit from

The benefits of SharePoint for those items are far outweighed by the cost aspects of learning, coding and supporting SharePoint. ASP.NET has easy solutions for these items and in a much more manageable way. Having used both products you will want to stay with ASP.Net

Remeber that SharePoint lists do not have any kind of relational integrity so creating anything more than a trivial relationship between lists in SharePoint will end up massively more expensive than creating a join statement and a few stored procs.

Without knowing more details of the project, I cannot completely rule out SharePoint as being a solution.

While it is possible to use SharePoint as a developement platform, if you do not have SharePoint experts working with you that could answer your question, you will not have enough SharePoint skills on your project to make it a success.

Answer 3

Scalability
License Restrictions
Extensibility
Complexity
Conceptual Integrity (domain boundaries)
Vendor Lockin/Open Systems Support
Redundancy/Replication/Backup/Recovery Support

Answer 4

Officially, in order to develop WSS solutions, all your developers will need to have their development environment run on a WSS server. I consider that to be a negative.

See the many comments under Sharepoint tools support in Visual Studio by Somasegar.

I'd say that since you have a short deadline, you also consider the fact that there is a much smaller SharePoint developer community than there is an ASP.NET community. Compare the number of articles on SO tagged with "ASP.NET" as opposed to those tagged "SharePoint".

I'd go with ASP.NET in the short term, understanding that you may be able to refactor your application to use SharePoint in the longer term. Use a database structure similar to the list or other content types you would have created in SharePoint. Keep a similar deployment model. Feel free to use workflow, but it should probably parallel the workflow features of SharePoint. You could even lay out your pages in a similar manner. This will make it easier to move to SharePoint when you have more time.

Answer 5

We use SharePoint as a component for most of the applications we build for its ability to create and manage lists and content types (and auto-CRUD), versioning, permission model, and workflow tools.

We developed SLAM, SharePoint List Association Manager, to overcome the obvious limitations in terms of SharePoint data not being relational. Because it pushes SharePoint data to SQL Server, it allows us to use SharePoint only on the "backend" with only ASP.NET on the front end, a configuration we use often.

We have released SLAM as an open source project so the rest of the development community can take advantage of this approach and help us extend it.

http://slam.codeplex.com

Happy Slamming!

Allan