Какие концепции разработки SharePoint сложнее всего понять разработчикам ASP.Net?

Question

Я пытаюсь собрать учебные материалы по SharePoint 2007 (и, возможно, в 2010 году) для опытных разработчиков ASP.Net, и, пройдя SharePoint годами, я не помню, где были худшие точки соприкосновения в начале - не говоря уже о том, что объем содержимого Googlable SharePoint на порядок больше, чем два года назад.

Тем не менее, какие концепции SharePoint труднее всего понять, и / или какие части SharePoint достаточно эзотеричны, чтобы быть неочевидным для начинающего разработчика SharePoint, только начинающего изучать?

Answer 1

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

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

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

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

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

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

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

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

Answer 2

Грег

По моему опыту, выдача, относящаяся к правильному удалению объектов ( SPWeb и SPSite объекты, которые, в свою очередь, ссылаются на SPRequest обертки вокруг неуправляемых объектов COM) общая проблема и источник многих проблем с масштабируемостью, производительностью и другими проблемами кодирования. Когда Microsoft осознала масштаб проблемы и степень замешательства разработчиков в этой области, они написали большую руководящую статью (http://msdn.microsoft.com/en-us/library/aa973248.aspx) и разработали инструмент SPDisposeCheck (http://code.msdn.microsoft.com/SPDisposeCheck).

).

Это мой голос за "неочевидное для начинающего разработчика SharePoint, который только что погрузился": -)

За что это стоит!

Answer 3

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

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

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

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

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

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

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

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

Подробнее об этом см. На Почему разработчики ASP.NET не используют WSS? в SharePointDevWiki.

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

Все, что связано с реальной архитектурой и реализациями. Я разработчик, но мне нужно испачкать руки, если я хочу иметь как можно ближе клиентскую среду в своих виртуальных средах, не дожидаясь официальной поддержки ИТ. Попробуйте создать небольшую ферму с интранетом, Интернетом, экстрасетью, смешанным механизмом аутентификации, сопоставлениями альтернативного доступа, настройкой заголовка узла и т. Это целая работа, но вам придется углубиться в нее, если вы хотите разработать средние и крупные реализации.

Answer 7

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