locked
ASP .Net aspx web pages Versus Webparts RRS feed

  • Question

  • Hi,

     

    We have a web application which uses sharepoint document library and lists to create documents, this web application is developed using .Net 2.0  and deployed on Sharepoint server but as a seperate website. The website is called from a Page Viewer Webpart in Sharepoint.I would like to know since the code uses the sharepoint webservices and called from within Sharepoint website is it better to develop it as a webpart or leave it as a web application? What are the Pros and Cons of using a webpart?

     

    Thanks,

    Janu

    Wednesday, August 22, 2007 6:34 PM

Answers

  • That is a question that could initiate a lengthy design discussion. SharePoint is just a platform, so some questions I would want to answer for myself would be:

    • Pre-existence of a site
      • If the web app is already written, then integration options become a likely route since rewriting an entire app may not make sense.
      • If you're developing a new piece of functionality and it does not add anything over what SharePoint offers, perhaps building on the SharePoint platform is a good idea.
        • In this case a SharePoint Solution could be designed with Features etc. and SharePoint could assume the role as your back end data store.
    • Performance
      • Obviously I don't want to call web services if there is a direct call I can make. All the API calls in SharePoint are essentially data base calls but taking those calls and then wrapping them in them in CAML is never the most efficient mechanism. We decouple systems with web services etc. to improve maintainability and make change easier to accomodate. When things are easier to change they are inherently less efficient.

    From what you have described you are exposing SharePoint libraries to another application that simply allows users to create documents in SharePoint via SharePoint web services. I would seriously look at what added value this is bringing since the performance implications are high as is the added complexity.

    Thursday, August 23, 2007 8:41 PM

All replies

  • That is a question that could initiate a lengthy design discussion. SharePoint is just a platform, so some questions I would want to answer for myself would be:

    • Pre-existence of a site
      • If the web app is already written, then integration options become a likely route since rewriting an entire app may not make sense.
      • If you're developing a new piece of functionality and it does not add anything over what SharePoint offers, perhaps building on the SharePoint platform is a good idea.
        • In this case a SharePoint Solution could be designed with Features etc. and SharePoint could assume the role as your back end data store.
    • Performance
      • Obviously I don't want to call web services if there is a direct call I can make. All the API calls in SharePoint are essentially data base calls but taking those calls and then wrapping them in them in CAML is never the most efficient mechanism. We decouple systems with web services etc. to improve maintainability and make change easier to accomodate. When things are easier to change they are inherently less efficient.

    From what you have described you are exposing SharePoint libraries to another application that simply allows users to create documents in SharePoint via SharePoint web services. I would seriously look at what added value this is bringing since the performance implications are high as is the added complexity.

    Thursday, August 23, 2007 8:41 PM
  • Very interesting discussion, it made me wonder if ASP.net apps will have anything to offer over Sharepoint solutions anyways!

     

    My department has many ASP websites and recently a Sharepoint site under the enterprise. I've been thinking about the best way forward to consolodate all functionality in one structure: All Sharepoint or integration of old services with SP?

     

    Notice that Sharepoint server is not directly under my control. I have adimin power of the ASP sites hosting server.

    Thursday, October 4, 2007 5:04 AM