Professional? application development with SharePoint 2010

Posted on 2013-12-09
Last Modified: 2013-12-17
What is the best practice for developing sharepoint applications?

Since last year we had to work with multiple SP applications. All of them were running on external farms with SP2010, so we can only use sandbox solutions.
At the beginning we had to change some implementations of list interactions from C# to JS. All actions of these dynamic masks were terribly slow because of the full postbacks and rerendering of the whole mask after user interaction.

- This sounds silly. Why we must retrieve the data via webservice and render content via JS instead of using the DB "near" SP to do this job?

- There is Nintex Forms/Workflow installed. But all these "clicky" stuff has a reliability problem. Who has changed what when and why in detail?
In normal applications all updates are first saved in a CVS

- Whats about portability?
How we get the actual "is" of an application from one SP (test) to another (prod) or vice versa. On "going live" of a new version we need the first, on bug comprehension the second. The data on prod must never be lost. When working with multiple developers - how we can merge the work of each?

- When using VisualStudio, what is about SoC? Why we have to create/layout/fill controls via C# CreateChildControls instead of using templates/views?

- VS support possibility seems to be realy poor? With SPSF we can "easily" (this plugin often crashed with huge stack traces when opening files. Only disabling and reenabling solves the problem) define types. But thats all? How we can do something with this information? In a normal application we would create a central model which can be used everywhere - with SP we only have the stringy stuff and no IDE help at all?

- Most of the applications are "living": they change monthly, get and looses contenttypes, colums, lists. Must each change be an additional feature which relies on the existing and must additional be activated? The feature list will be realy big after short time

So much questions

Kind regards
Question by:maxworx
  • 2
  • 2
LVL 31

Accepted Solution

Jamie McAllister MVP earned 500 total points
ID: 39705775
There's no quick answer to the questions you pose. The reason that you're seeing remote service call based solutions as well Sandboxed solutions is really down to a shift in the industry as a whole to hosted farms and cloud.

I've written about this here, and happy to discuss further;

Author Comment

ID: 39711099
If we use external "services" where starts SP and where does it end?

- Frontend?
As pointed above there are many problems with SP

- Database?
At the end its a "simple" SQL Server

- Backend?
In my opinion the strengths and weaknesses of sharepoint are both here.
The possibility for ease definition of colums, content types, lists and librarys. Automatic creation of version, connecting features and many more.
But if there is the need for complexibility then we will be lost in hundrets of menus and/or the lack of customization options. Often often a huge part of the application must be dropped and recreated for some little required change.

I don´t know who told customers SharePoint can do "everything" (wait... MS does). Now all want SP applications and do not understand why most of the functions take a long time: "hey, we click here and there and now we got something that looks like what we want" ... well, it looks like but its far away from what you realy want to do with ...
If you want to develop something of the complexity of SharePoint - you can´t use SP as plattform and expect it will be fast developed and perform in a excellent way
LVL 31

Assisted Solution

by:Jamie McAllister MVP
Jamie McAllister MVP earned 500 total points
ID: 39711125
From the beginning of SharePoint's mass market appeal, it's never been easy to resource or run a SharePoint development project. The strength of SharePoint is the large amount of capabilities you get out of the box. As you say, it's typical that we have to tell the user the complicated change will take 5 minutes, and the seemingly easy change will take 5 weeks.

Full trust solutions are losing favor. This isn't a problem for some types of solution, as mentioned we can code outside of SharePoint and use it's interfaces to call in and perform actions. We can use script to achieve UI elements (and tools like TypeScript might help us do that in an Enterprise friendly way).

Will SharePoint development ever be easy? Well, I've waited a few versions and the tool support has improved a great deal, but there's still quite a learning curve to really get the platform. I suspect that learning curve will always exist.

Author Closing Comment

ID: 39724009
Thank you for spending time. The answers doesn´t make me happy but confirm my impressions

Featured Post

Salesforce Made Easy to Use

On-screen guidance at the moment of need enables you & your employees to focus on the core, you can now boost your adoption rates swiftly and simply with one easy tool.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Does the idea of dealing with bits scare or confuse you? Does it seem like a waste of time in an age where we all have terabytes of storage? If so, you're missing out on one of the core tools in every professional programmer's toolbox. Learn how to …
A short article about problems I had with the new location API and permissions in Marshmallow
This tutorial covers a step-by-step guide to install VisualVM launcher in eclipse.

821 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question