В этой статье хочу описать, что делать, если решили написать высоконагруженное корпоративное решение на SharePoint, и показать реализацию вышесказанного на примере решения EOS for Sharepoint 3.5.
Для тех, кто не любит много читать, кратко по ссылке:
- данные всех списков (кроме библиотек документов) семейства сайтов в Sharepoint хранятся в одной таблице контентной базы;
- индексы списков обслуживаются не СУБД, а встроенными механизмами Sharepoint;
- неразумное использование индексов в списках может снизить быстродействие системы.
У подхода, принятого в Sharepoint, есть свои плюсы – для хранения неструктурированных данных схемы БД Sharepoint подходят неплохо, и, при использовании дополнительных средств Sharepoint Server создать мощный кор. портал для большой организации не представляется чем-то очень сложным.
Но если решение должно работать на SP Foundation и обрабатывать большие объемы структурированных данных (например, карточки документов и связанные с ними поручения, журналы, файлы) – так или иначе придется использовать внешние источники данных.
Наиболее подходящие и «родные» для Sharepoint варианты хранения данных во внешних базах – это использование BCS и ServiceApplications. От использования BCS разработчики ЭОС (и не только они) по многим причинам отказываются, поэтому в этой статье речь будет идти о создании базы данных в приложении-службе.
Разработку части решения, отвечающую за работу во внешней БД можно разделить на несколько больших этапов, каждый из которых я кратко опишу.
Этап 1. Создание приложения-службы.
Как пишут на MSDN «Создание собственных приложений-служб SharePoint 2010 является нетривиальной задачей» и требует хорошего понимания архитектуры Sharepoint, зато в награду – решение в стиле Sharepoint, масштабируемость и прозрачность для администратора.
Полное описание алгоритма создания приложения-службы выходит за рамки статьи, для желающих обучиться есть немного информации на MSDN.
Чтобы создать свое приложение-службу, нужно создать класс, унаследованный от SPServiceApplication. Например, в EOS4SP 3.5 этот класс выглядит так:
После этого нужно создать свой класс базы данных, унаследованный от SPDatabase, и это как раз то место, где можно определить структуру создаваемой БД (или, точнее, вставить ссылки на свои скрипты для создания базы). Для этого нужно переопределить метод Provision (пример реализации в EOS4SP на рисунке ниже) и запустить в нем встроенный SPDatabase.Provision с нужными параметрами:
Этап 2. Синхронизация данных в БД со списками Sharepoint.
Синхронизацию можно разделить на первичную и постоянную. С первичной, думаю, все понятно (можно, например добавить страницу с обработчиком в центр администрирования), а вот с постоянной – все зависит от потребностей – можно поместить в TimerJob, но оперативнее будет обновлять запись в БД одновременно с элементом списка, в EventReceiver или в переопределенных кнопках FormTemplates.
В EOS4SP 3.5, например, задействовано оба механизма:
- Переопределение кнопки SaveButton в форме типа контента вызывает метод SaveItem класса EServiceAccess (класс для обработки данных в базе).
- Для удаления элемента используется EventReceiver, вызывающий метод DeleteItem класса EServiceAccess:
Таким образом, в ходе постоянной синхронизации, данные в списках Sharepoint могут быть продублированы во внешней таблице и могут быть получены быстро или очень быстро.
Шаг 3. Получение и отображение данных из внешней БД
Когда данные загружены в базу, нужно продумать механизм их отображения. Здесь четких инструкций нет, разработчик на ASP .NET может выбрать любой удобный для себя механизм (GridView, например), но все же предпочтительнее использовать контролы в стиле Sharepoint и помещать их в связываемые веб-части. Например, веб-часть для отображения данных и веб-часть фильтра могут быть расположены на одной странице и соединяться друг с другом, именно так как сделано в EOS for SharePoint. Если сделать контрол похожим на XSLTViewWebPart, то будет совсем хорошо, но сделать это непросто, и не всегда оправданно.
Вот, собственно, и все, что нужно для успешной работы решения с внешней БД. В результате получаем:
- прирост в быстродействии (при небольшом количестве элементов в среднем в 1.5 раза, при большом — в 2 раза);
- масштабируемость (приложение-службу можно размещать на нескольких серверах);
- возможность администрирования и настройки баз средствами СУБД.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий