Структура моих SharePoint проектов

Структуру своего первого SharePoint проекта я строил, руководствуясь принципами и практиками, которые я выработал, будучи ASP.NET разработчиком. Модульность, слабая связанность между частями проекта, точки агрегации зависимостей – все эти принципы так же удачно ложатся в основу структуры SharePoint проекта, как и в структуру большинства проектов созданных на основании других технологий. Если для вас эта тема нова или же хотите ее освежить, то я настоятельно рекомендую вам ознакомиться с серией статей Simon Ince посвященных созданию архитектуры на базе принципов заложенных в Microsoft Web Client Software Factory. В свое время они перевернули мое представление о том, как надо структурировать проекты.

10 фактов о SharePoint, которые не помешали бы мне год назад

1. Используй виртуальную машину.
Сразу бери/проси машину помощнее, тебе понадобится, как минимум процессор i3/i5 и 8 gb памяти, чтобы поднять виртуальную машину в которой и будет вестись вся разработка. Работая в виртуальной среде, ты сэкономишь себе кучу времени и нервов, т.к. в случае чего – всегда можно откатиться к предыдущему snapshot-у, а при старте нового проекта восстановить исходное состояние системы с чистым SharePoint всего за пару кликов. Ну а если разработка ведется сразу в двух ветках одного проекта (скажем, branch с фиксами для прошлого релиза и trunk с новой функциональностью), то без возможности переключаться между snapshot-ами просто никак. Выбор платформы остается за тобой, но я, лично, предпочитаю связку VMWare + Windows 2008 R2.

2. Выработай четкую политику накатывания обновлений.
С webpart-ами, формами и т.п. у тебя не должно возникнуть никаких проблем при накатывании новых изменений, т.к. при их re-deploy ты ничего не потеряешь, но вот с полями, типами, списками и рабочими процессами тебе придется помучиться. Постарайся четко определиться (а ещё лучше как-то автоматизировать) каким образом ты будешь накатывать изменения на production сервер. Я для себя выбрал следующую тактику: при внесении какого-либо изменения в схему списка или контентного типа тут же создается PowerShell скрипт, позволяющий накатить те же самые изменения на предыдущий релиз, развернутый у заказчика и на тестовом сервере. Скрипты упорядочиваются по задачам, к которым они привязаны и номерам версий. Feature Upgrade, конечно более естественный для SharePoint механизм накатывания изменений на схему, но у меня с ним возникала куча самых разных проблем.

3. Нет, от конетекста SharePoint тебе не отвязаться.
Поначалу я очень-очень старался скрыть от слоя бизнес-логики тот факт, что (о ужас!) она взаимодействует с SharePoint. Подсовывал всякие DTO и DataModel объекты, генерировал фасады и медиаторы, сервисы-провайдеры и репозитории. Но все это бесполезно, не тратьте впустую время – ты работаешь с SharePoint, так что изволь играть по его правилам. Передавай SPListItem-ы в сервисы уровня BLL, которые отвечают за назначения прав доступа, прокидывай SPWeb сквозь View в Presenter и далее в Model. Да – некрасиво, да – очень сложно тестировать. Но иначе ты просто рискуешь запутаться из какого контекста пришел тот или иной объект (страница/ресивер/таймер) и увязнуть в тонне фасадов, созданных на каждый случай. Улучшай читаемость, степень повторного использования кода внедряй модные паттерны и разделяй на слои, но делай это все в духе SharePoint.

4. Разделяй и властвуй.
Советую сразу выделять все, что связано с уровнем хранения данных (поля, типы, списки) в отдельные проекты. Это существенно упростит процесс deploy и отладки. Рабочие процессы, кстати, тоже по-хорошему надо выносить в отдельный пакет.

5. EventReciver-ы не так просты, как кажутся.
Если у тебя есть задача, которая решается при помощи EventReceiver-ов и это твоя первая встреча с ними – не торопись. Они только с виду кажутся простыми, а на практике с ними столько заморочек. Лучше сядь, прочитай главу про EventReceiver-ы в какой-нибудь умной книжке (мне, кстати, нравится Jorg Krause – SharePoint 2010 as a Development Platform (amazon)) и серию из двух статей в блоге gandjustas-а (часть 1, часть 2). А затем определить какой именно из Receiver -ов тебе нужен, и не спеша, вдумчиво приступай к реализации. Я в свое время потратил кучу времени и нервов, пытаясь с ходу реализовать сложный Receiver.

6. Использовать Linq To SharePoint не самая лучшая идея.
Я вот тоже очень обрадовался, когда узнал, что в SharePoint 2010 теперь есть настоящий Linq для работы со списками. Сразу же кинулся все на нем реализовывать и только потом понял, что зря я это сделал. Linq2SP предоставляет очень скудную функциональность по работе со списками. Если ты реализуешь что-то, действительно, серьезное, то почти наверняка придется плодить параллельную иерархию на основе объектной модели SharePoint (SPListItem, CAML и т.п.). А дублирование кода никогда ни к чему хорошему не приводило. Плюс, к тому же, ты его никак не контролируешь и из-за этого можно очень легко накосячить с производительностью. Но если все-таки хочется чего-то Linq-ушного, то бери на вооружение Camlex. Вещь неплохая, хорошо встраивается в существующие SharePoint проекты, да и к тому же он OpenSource.

7. Есть много плагинов и приложений, которые упрощают работу с SharePoint.
SharePoint Software Factory – сборник “рецептов” и полезных утилит для работы с SharePoint. Особенно советую обратить внимание на возможность копирования файлов напрямую в GAC/Hive, минуя deploy (неплохо экономит время) и на attach к процессам SharePoint(IIS, Timer) для отладки.
CKS – Development Tools Edition - почти тоже, что и Software Factory, но без рецептов.
ULS Viewer – утилита для работы с логами SharePoint. Он там пишет очень много всего интересного. В случае возникновения непонятной ошибки в первую очередь советую заглянуть именно туда.
SharePoint Manager 2010 – Невероятно полезная утилита. Позволяет посмотреть структуру сайтов SharePoint и получить схемы всего и вся. Много раз выручал меня.
U2U Caml Query Builder – Утилита для построения CAML запросов. Удобно, просто, наглядно.
SPDisposeCheck – Проверяет проекты на предмет утечки памяти. Запускай время от времени, а ещё лучше, интегрируй в свой Continuous Integration сервер.

8. PowerShell твой лучший друг.
Серьезно, не пренебрегай им. На PowerShell очень просто писать патчи для обновления схем и небольшие утилиты для автоматизации каких-либо действий. В качестве IDE я советую использовать PowerGUI.

9. Не забывай освобождать ресурсы.
Надеюсь, ты уже в курсе, что часть SharePoint реализовано с использованием COM, и что такие объекты как SPSite и SPWeb тянут за собой неуправляемые ресурсы, которые надо явно высвобождать через Dispose? Вот я когда-то не знал и очень удивлялся, когда через день активной работы SharePoint забирал себе всю память, и ни в какую не хотел ее отдавать назад. Так что следи за каждым созданием SPSite и SPWeb, прочитай эту статью на MSDN и время от времени запускай SPDisposeCheck (см. п.7).

10. SharePoint с налету не взять.
Когда мне предложили попробовать себя в роли SharePoint разработчика я подумал: “Хм, а почему бы и нет? Я вроде бы поднаторел в изучении новых платформ. IPhone и Flex пошли на “ура”. А SharePoint, это всего-навсего надстройка над ASP.NET. Легко!”. Как окажется позднее – я сильно ошибался, SharePoint с налету не взять. Будь сразу готов к тому, что у разработчиков SharePoint было свое мнение по поводу того, что логично, а что нет. Тебе придется потратить кучу времени, раскапывая тонны javascript-ов и xml-ек, чтобы разобраться, как добавить одну единственную кнопку, без которой заказчик не хочет принимать форму. Для меня SharePoint это один большой Challenge. Читай книжки, блоги, выискивай статьи на msdn, общайся на форумах и будь готов к сложностям. Впрочем, как раз из-за обилия этих сложностей нам хорошо платят и мы нужны всем.

Буду очень рад, если кто-то захочет дополнить этот список и поделиться своим опытом работы с SharePoint. Пишите, комментируйте!

* – хотя, корректнее, было бы сказать мыслей или знаний полученных в результате практической работы с SharePoint.

Разработчик о SharePoint

Как я провел лето (или мысли разработчика о SharePoint)

Microsoft SharePoint 2010 Server представленный корпорацией Microsoft является ничем иным, как очень мощным инструментов для построения документо-оринетированных систем. Но эта “мощность” SharePoint, как платформы носит двуликий характер: с одной стороны, он предоставляет широкий спектр инструментов и функций для работы с документами (и другими абстракциями описанными в рамках системы), но с другой стороны – разработчику крайне тяжело(а, порою, и вовсе невозможно) менять абстракции и процессы лежащие в основе платформы.

C# | Manage local & domain groups – II

Некоторое время назад я писал про работу с доменными и локальными группами. Представленное мною решение является вполне рабочим, но тем не менее, у него есть один недостаток – оно позволяет работать лишь с одним из доменов в котором находится машина исполняющая программу. Если быть точнее – с тем доменом который вернется в результате выполнения метода Domain.GetComputerDomain().

Сегодня я хотел бы написать об улучшенной версии. Методы были подвергнуты тотальному рефакторингу + добавилась возможность явно указывать домен в котором будут производиться манипуляции над группами.

C# | Get current platform (x86/x64)

В этом посте я приведу фрагменты кода для определения типа системы (32-х или 64-х разрядная) на которой исполняется приложение.

(Скачать)

C# | Manage Local Users & Groups

На этот раз рассмотрим работу с локальными пользователями и группами в C#.

1. Создание пользователя.
2. Создание группы.
3. Добавление пользователя в группу.
4. Проверка, существует ли группа с заданным именем.
5. Проверка, является ли пользователь членом группы.

(Скачать)

C# | Manage Domain Users & Groups

В данной статье приведены примеры работы с доменными пользователями и группами в C#.

1. Создание пользователя.
2. Создание группы.
3. Добавление пользователя в группу.
4. Проверка, существует ли группа с заданным именем.
5. Проверка, является ли пользователь членом группы.
+ Флаги, описывающие тип доменной группы.
+ Флаги, описывающие параметры пользователя.

(Скачать)

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!