Являются ли списки SharePoint злыми в предприятиях, основанных на SOA?

Question

Моя компания переходит от клиент-серверных приложений (толстые клиентские приложения, которые непосредственно обращаются к базе данных) к сервис-ориентированной архитектуре (SOA) (тонкие или толстые клиенты, которые вызывают веб-службу, которая затем выполняет бизнес-логику и вызывает базу данных) .

Часть этого включает использование SharePoint в качестве нашего клиента (не только нашего типа, но и основного). Я наблюдал за обучением Pluralsight по SharePoint, и я начинаю видеть много о списках SharePoint.

Списки SharePoint, кажется, являются основной частью SharePoint. Однако они также кажутся огромным шагом назад в архитектурном отношении. Это мои проблемы:

• Используя эти списки, мои веб-части SharePoint будут снова напрямую обрабатывать данные (как и в случае с двухуровневыми приложениями клиент / сервер).
• Это сбивает с толку слой данных большое время. Хранить ли мой список клиентов в базе данных SQL Server? Или список SharePoint? Или оба? (скажем, это не так!) Если и то, и другое, как мне их синхронизировать?
• Если я храню данные в списках SharePoint, нужно ли мне иметь свои веб-службы, использующие клиентскую объектную модель SharePoint, для доступа к спискам (для клиентов не из SharePoint)?

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

Списки SharePoint выглядят как попытка хранения данных низкого качества. (Без всех преимуществ полноценного решения для управления данными, такого как SQL Server.)

Итак, вот мои вопросы: Каковы правильные / оптимальные причины, по которым мне следует использовать списки SharePoint через веб-службы, которые обращаются к SQL Server? И может ли SharePoint даже нормально работать, используя веб-службы для получения и обновить данные? (В основном, если я не использую списки, я теряю много функциональности?)

Answer 1

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

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

SharePoint 2010 значительно расширяет возможности SharePoint 2007 с помощью Business Connectivity Services, обеспечивая полное чтение и запись из списков SharePoint, а доступ к API позволяет реализовывать пользовательские соединители в коде для любой серверной системы, к которой вы можете пытаться получить доступ Поставщик SQL Server предоставляется из коробки). Вот довольно подробный учебник по BCS, и в MSDN можно найти гораздо больше информации.

Будьте осторожны, пытаясь использовать списки SharePoint в качестве традиционных таблиц в СУБД, это не их назначение, и это только приведет к сильным головным болям в будущем.

Answer 2

Хотя я согласен с ответом OedipusPrime, я чувствую, что ваш вопрос «Зачем мне использовать списки» требует более подробного ответа.

Короткая версия, вы, вероятно, не должны. SharePoint дает вам списки, которые немного похожи на базы данных, но достаточно просты, чтобы ваш обычный пользователь мог справиться с ними. Они довольно гибкие для пользователей. Он также предоставляет вам пользовательский интерфейс для взаимодействия со списками и данными.

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

Итак, где бы вы хранили свои данные? SQL или списки. Один или другой - не делайте и того, и другого, что никогда не получается хорошо. Если ваши данные в SQL, вы можете предоставить их в SharePoint с помощью BCS, как уже упоминалось.

Если ваши данные находятся в списке SharePoint, да, вы можете использовать объектную модель клиента. Или вы можете использовать веб-сервисы напрямую. Или REST API. Все это допустимые параметры.

Или вы можете предоставить данные из своей базы данных через свои собственные веб-службы, а затем использовать их через BCS SharePoint, что позволит вам представлять свои данные в SharePoint (с полным CRUD, если хотите), без того, чтобы приложение стало зависимым от него. .

Answer 3

Это один из самых больших вопросов, с которыми сталкивается новичок в SharePoint. Стоит ли хранить X в списке SharePoint или в таблице SQL Server?

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

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

Слово предупреждения: ни в коем случае не поддавайтесь искушению напрямую взаимодействовать с базами данных контента SharePoint.

Answer 4

Вы частично правы.Что касается ваших вариантов, вот маршрут, по которому вы должны идти:

Вы должны хранить данные только в списках.Не в SQL-сервере.Данные в списках в конечном итоге хранятся в базе данных контента SharePoint на сервере SQL, и нет смысла синхронизировать их.

Чтобы ваши клиенты имели доступ к данным, ваши веб-службы могут вызывать готовые веб-службы, представленные в SharePoint.который может работать с данными списков.

См. эту статью с обзором веб-служб, предоставляемых SharePoint: http://msdn.microsoft.com/en-us/library/ee538665.aspx http://www.sharepointmonitor.com/2007/01/sharepoint-web-service/