Что понятия разработки SharePoint являются самыми трудными для разработчиков ASP.NET понять?

Мой список вещей, которые сложнее всего понять:

• Безопасность доступа с помощью кода и все другие функции безопасности
• Разница между сайтом / приложением страницы и индивидуальные / ненастроенные страницы
• CAML в обоих запросах и во всех определения
• Что уже есть в SharePoint, так что вы не изобретайте велосипед

• Отказ от контроля.

  Вы не контролируете, какие веб-части на странице и как они связаны. Вы должны просто дать им возможность повторное использование

  Вы не контролируете, какой список находится в сайт или какие поля они содержат

• Отсутствие поддержки нескольких languages ​​
• Не удаляйте SPWeb и SPSite, если вы получить их из SPContext.Current
• делегировать элементы управления

Другие вещи, которые являются новыми, но кажутся более легкими для понимания:

• Решения / функции
• Все заполнители на мастер-страницах

* Отсутствие контроля *

Это ключевая проблема, как Пер Якобсен упоминает . Продолжаем ...

1. Невозможно просто войти и отредактировать файлы .aspx и .master, где бы вы ни захотели. Есть последствия, такие как отключение хостинга, поддержка, и то, что это часто просто не работает, как можно было бы ожидать. Хорошее понимание того, как SharePoint составляет страницы, имеет решающее значение.

2. Нет (поддерживаемого и надежного) способа напрямую запросить базу данных. Это крайне неприятно для разработчиков ASP.NET, которые привыкли проектировать / работать со специально созданными и хорошо спроектированными базами данных. Запросы CAML не заменяют мощь хорошо оптимизированных запросов SQL.

3. (скорее 2b): Плохая поддержка реляционных данных между списками. Странно для корпоративного приложения.

4. Немного не по теме, но разметка HTML и CSS были кошмаром в 2003 году и ненамного лучше в 2007 году. Работать с ним больно, и это тоже неприятно. Вы должны пойти на многое, чтобы создать сайт, полностью соответствующий веб-стандартам и передовым практикам.

Подводя итог, обычно нужно делать что-то «по принципу SharePoint». Часто это не самый эффективный или элегантный способ, который предпочитает обычный разработчик ASP.NET. Разработчики любят элегантность, и им не нравится отказываться от контроля.

В продукте также есть подводные камни ( Шон упомянул ключевой ), скрывающиеся, как маленькие проволочки для ничего не подозревающих. . Единственный способ узнать и понять их - это знать SharePoint - а это большой продукт.

Подробнее об этом см. Почему не ASP.

Пер покрыл для меня большую часть вопросов, однако я добавлю еще пару:

1. SPContext - Концепция выполнения произвольного кода, например, SPContext.Current или объект Properties в приемник событий.

2. Исходя из контекста, также важно понимать, под кем работает код и какие действия он может выполнять - повышение (повышение привилегий), выдача себя за другое лицо (токены) и выполнение (веб-службы / получатели событий).

3. Обработка ошибок - Все кричат, когда обнаруживается единственная ошибка «Произошла ошибка», поэтому понимание журналов SP и кодов ошибок очень важно. Это важно для сокращения потерь времени на поиски раздражающей ошибки XML.

4. Инструменты Visual Studio - WSPBuilder, VS Tools для Sharepoint и т. Д. Упростите развертывание и отладку, сократив цикл интеграции.

Это абсолютно законно. Т.е. SELECT id FROM entries WHERE author_id IN (SELECT id FROM authors ORDER BY name DESC) , но обычно получаются те же результаты.

Если вы не используете верх, это не полезно, так как вы будете заказывать во внешнем запросе в любом случае

Что уже есть в SharePoint, чтобы не изобретать колесо заново. Я голосую за это.

Создание отчета / приборной панели, используя службы отчетности SQL Server для реальных проблем с мировыми проблемами и показать его на сайте SharePoint. Количество примеров / учебных пособий нашел онлайн Нет, этот вопрос все еще недостаточно (я думаю).