Professional? application development with SharePoint 2010

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
Who is Participating?
Jamie McAllister MVPSharePoint ConsultantCommented:
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;
maxworxAuthor Commented:
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
Jamie McAllister MVPSharePoint ConsultantCommented:
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.
maxworxAuthor Commented:
Thank you for spending time. The answers doesn´t make me happy but confirm my impressions
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.