locked
ASP.Net vs. Sharepoint for web app RRS feed

  • Question

  • I know this is a big topic for one post but I thought I'd pick your all's brains. We are doing a rewrite of a web application and trying to decide on the new technology to use. Our organization is heavily invested in Sharepoint, but could be open to doing this as a ASP.NET app. I'm hoping I can just get your opinion on the appropriately technology. I've got some concern about using Sharepoint.

    Let me briefly describe the application running in production now:

    • ColdFusion
    • SQL Server 2008R2 DB
    • Maintains records for roughly 5000+ employees
    • Interfaces with PeopleSoft data to get information such as job title, start date, etc.
    • Application is used for tracking records and is generally a series of forms to add these records for employees. E.g. Employee John Doe completes "New Employee Training". One row is added to "Employee_Training" table for John Doe.
    • Database is normalized (e.g. "Employee_Training" would have FK to EmployeeId, DeptId, etc.)
    • Several stored procedures used to interact with tables (e.g.s. spAddTraining, spDeleteTraining, spGetDepartment, etc.)
    • Some canned reports
    • Only one or two users at a time

    The new system would function pretty much the same way, but needs to be more user friendly. Right now, the GUI is really outdated looking, and it takes too many clicks to do updates.

    Okay, here's where I'm at:

    My background is primarily in Java and have just used Sharepoint as a user and some admin, but not development. With .NET, I've done mostly Business Intelligence projects, no sophisticated web apps.

    With Sharepoint, I could quickly create several lists/libraries. We'd immediately be able to leverage Sharepoint's filtering, alerts, security features, etc., not too mention the look-and-feel is clean and comfortable to our users. We can use Infopath for forms.

    Some of my immediate concerns include porting historic SQL server data into Sharepoint. I've used the Sharepoint list adapters in codeplex before, and thought I might use SSIS to bring the data over. That said, does it make sense to try to recreate a normalized database as lists in Sharepoint? Would I want to use external content types to reference the existing db? I worked on one other SP project, and extensibility was an issue. Any time clients asked for a new function, it seemed like the lead developer had to move heaven and earth to get it in. Also, have you all found issues with migrating sites between environments (dev, test, prod)? Suggestions for interfacing with PeopleSoft? We have Linked Server in SQL Server, but is it something I could even use with SP?

    Ultimately, would we be insane to even to attempt jimmying this application into Sharepoint? I know it has some decent out-of-the-box functionality and is good for simple document management. My feeling is that I could quickly customize it to get 70% of what we need but it's that last 30% that has me worried. My upper management will cringe if I say I'd rather build from scratch with ASP.Net when they've spent beaucoup dollars on Sharepoint, but I'm not sure it's a good fit.

    Thanks,

    Marc

    Monday, February 25, 2013 10:25 PM

Answers

  • Lists are not relational, so I think you would consider using your existing database and use a BCS connection.  You could provide create/update/delete methods via SharePoint's UI to this database.  You could also call out any database directly via any provider that is registered with the system.

    What SharePoint could handle for you is the overall UI as well as security model, but even that would likely be customized to suit your company's needs (this application sounds a lot like my company).

    I came from writing ASP.NET (using VB.NET and later C#) to SharePoint farm-based solutions in C#.  There is a (small) learning curve coming from ASP.NET/C# to SharePoint, and this is without touching the UI components.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, February 26, 2013 1:04 AM

All replies

  • Lists are not relational, so I think you would consider using your existing database and use a BCS connection.  You could provide create/update/delete methods via SharePoint's UI to this database.  You could also call out any database directly via any provider that is registered with the system.

    What SharePoint could handle for you is the overall UI as well as security model, but even that would likely be customized to suit your company's needs (this application sounds a lot like my company).

    I came from writing ASP.NET (using VB.NET and later C#) to SharePoint farm-based solutions in C#.  There is a (small) learning curve coming from ASP.NET/C# to SharePoint, and this is without touching the UI components.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, February 26, 2013 1:04 AM
  • Thank you for the reply, Trevor.  I will be having a meeting to discuss the alternatives with our Sharepoint gurus in my organization.  This has given me some food for thought.

    Thanks

    Tuesday, February 26, 2013 10:04 PM