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

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

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

С точки зрения разработчика

Модель предметной области

Microsoft SharePoint полностью инкапсулирует слой работы с SQL базой данных от разработчика, предоставляя свой набор базовых абстракций (поле, контентный тип, определение и экземпляр списка/документа) и инструментов (LinqToSharePoint, CAML, объектная модель) для взаимодействия с уровнем доступа к данным (DAL). Данный подход существенно упрощает создание новых сущностей предметной области, т.к. основные типы и абстракции уже описаны в системе. Так для создания нового типа документа обладающего стандартным набором атрибутов (Имя, Автор, Дата создания, и т.п.) достаточно воспользоваться предопределенным контентным типом “Документ”, который уже содержит необходимый набор атрибутов. SharePoint так же предоставляет удобные графические инструменты для формирования и редактирования сущностей уровня хранения данных.

Но, помимо вышеперечисленных преимуществ, данный подход обладает множеством недостатков.  Прежде всего, стоит отметить, что большинство разработчиков привыкли использовать в качестве хранилища данных реляционную СУБД. В этой области наработано огромное количество теоретического материала, практик и инструментов, которые существенно упрощают разработку системы, делая её прогнозируемым, сходящимся процессом. Подход к хранению данных, используемый в SharePoint почти полностью исключает возможность использования существующих практик. Остановимся более подробно на особенностях DAL в SharePoint:

Поля

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

Типы и списки

В роли аналогов таблиц реляционных СУБД в SharePoint выступают контентные типы и списки. Этот подход позволяет использовать некоторые концепции объектно-ориентированного программирования при проектировании уровня хранения данных. Но при этом утрачивается вся та гибкость в проектировании и оптимизации структур данных, которая возможна была с реляционной СУБД. Так же, в SharePoint имеются существенные проблемы с объемами хранимых данных (Microsoft не советует хранить более 5000 элементов в списке, что абсолютно неприемлемо для большинства задач. Решения этой проблемы существуют, но они требуют дополнительных трудозатрат и ведут к запутыванию логики приложения). И, на конец, SharePoint не поддерживает транзакционных операций при работе со списками и документами.

Выборка данных

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

Точки доступа

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

Изменение схемы хранения данных

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

Процесс разработки

Тестирование

Процесс тестирования системы написанной на базе платформы SharePoint существенно затруднен по сравнению с тестированием системы созданной на базе ASP.NET. Крайне сложно (а, порою, и вовсе невозможно) обеспечить идентичное состояние системы на тестовом сервере, сервере заказчика и машине разработчика. Автоматическое Unit-тестирование так же затруднено из-за того, что каждый запуск и выполнение теста может занимать до нескольких минут. Это делает почти невозможным использование таких практик, как Test Driven Development, которые могли бы существенно повысить качество разрабатываемого кода и снизить издержки на ручное тестирование.

Отладка

Одним из преимуществ современных сред разработки является возможность удобной отладки кода. При разработке на SharePoint почти все преимущества в отладке приложения сходят на нет. Каждое подключение к серверу в режиме отладки, как и в случае с тестами, может занимать до нескольких минут. Такое состояние дел превращает процесс отлаживания кода приложения в затянутый и скучный процесс, который разработчики стараются избегать, что, в свою очередь, ведет к снижению качества кода. Так же, стоит отметить систему логирования SharePoint. Это весьма мощный инструмент для диагностирования ошибок, но для его эффективного использования необходимо применять сторонние утилиты (ULSViewer).

Рабочее место

Не смотря на существенный прогресс в интеграции средств разработки SharePoint в Microsoft Visual Studio 2010 и в возможности разворачивания сервера на клиентской операционной системе (Microsoft Windows 7 x64), организация “комфортного” рабочего места разработчика по прежнему остается нетривиальной задачей. Прежде всего, для одновременной работ в Visual Studio и SharePoint Server рабочая машина должна быть оснащена мощным процессором и большим (6-8 gb) объемом оперативной памяти. Разработка на общим, выделенном сервере невозможна из-за необходимости в постоянных перезагрузках IIS сервера. Наиболее рациональным видится решение с организацией рабочего места в рамках виртуальной машины. Это позволит существенно сократить время на переустановку системы в случае, если SharePoint перестанет работать (такая ситуация довольно-таки часто возникает на машине разработчика и в ряде случаев исправляется лишь полной переустановкой операционной системы).

Концепции и структура

Отличительной чертой хорошо спроектированного приложения является четкая структура и соблюдение архитектурных концепций на всех его уровнях и во всех модулях. В классическом подходе привычном большинству разработчиков в архитектуре приложения явно выделяется три слоя: слой хранения данных, бизнес логики и представления. Как уже упоминалось ранее, в SharePoint сложно явно выделить слой работы с данными, т.к. в зависимости от текущего контекста (страница, обработчик события, рабочий процесс, и т.д.) варьируется способ доступа и изменения данных. Можно построить свой ORM(платформа и рынок не предоставляет готовых библиотек), но для решения ряда задач в рамках системы придется отходить от него, что только запутает архитектуру. То есть, классический подход к проектированию информационных систем не применим по отношению к SharePoint. Есть предположение, что каждая часть, каждый модуль должен выступать в качестве самостоятельной под-системы. Чем меньше будет общих абстракций и слоев – тем проще будет обеспечить работоспособность и производительность каждого модуля и всей системы в целом. При этом, разумеется, увеличивается время и сложность поддержки системы.

 

Итого

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

 

P.S. Все выше сказанное – это мое мнение, как разработчика, которое сложилось за 9 месяцев участия в проекте разрабатываемом на Microsoft SharePoint 2010.  Не смотря на то, что за это время мне пришлось очень плотно работать с платформой, я по прежнему не могу сказать, что понимаю, как именно нужно правильно разрабатывать приложения на SharePoint. Буду крайне признателен за конструктивную критику.