Разработка SharePoint и проекты, ориентированные на данные

Question

Я участвовал в проекте SharePoint (WSS), который был очень ориентирован на данные. Проект состоял из более 500 списков, которые имеют очень сложные отношения между ними. Клиент также запросил более 350 отчетов. Не говорите мне, почему вы использовали SharePoint с самого начала. Это было управленческое решение, и мы уже выполнили проект после 14 месяцев боли (это на 6 месяцев раньше срока)

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

В любом случае, мы изучали SharePoint во время разработки. В основе нашей разработки лежал конструктор SharePoint, который настраивал все AllItems / NewForm / EditForm / DispForm для каждого списка, чтобы обеспечить необходимую логику / проверку, которые запрашивал клиент (используя JavaScript). Мы также реализовали около 15 пользовательских полей (например, поля основных данных). Мы также создали приемник событий для обработки всех событий добавления / обновления / удаления ... для всех списков на сайте. Плюс около 40 пользовательских элементов управления ASP.Net.

Основные проблемы, с которыми мы столкнулись (мы обходили их, но, к сожалению, неэффективно)

1 - Клиент запрашивал веб-часть поиска в каждом AllItems.aspx. Поисковая веб-часть должна иметь несколько ключей для поиска клиентом. Мы сделали это с помощью веб-частей формы, используя SPD, без проблем. Но реальная проблема заключалась в том, как искать связанное поле, которого не было в текущем списке. (Таким образом, в таких случаях мы должны были сохранить значения этих полей в нашем списке, чтобы иметь возможность искать (дерьмо, я знаю !!)). Вы можете спросить, почему вы не реализовали пользовательские элементы управления ASP.Net для такой задачи? Что ж, это потребовало бы от нас отказаться от веб-части AllItems по умолчанию, и мы уже настроили множество страниц AllItems.aspx со множеством настроек, которые отнимали бы у нас много времени, чтобы заново реализовать их с самого начала. Кроме того, даже если мы использовали пользовательские элементы управления, CAML очень неэффективен для извлечения данных из нескольких связанных списков!

2- Я думаю, что вы можете догадаться об этом, если мы уже столкнулись с большим количеством времени, занимаясь поисковыми веб-частями, как же мы сможем сделать 350 отчетов !!: D Но мы нашли обходной путь (как обычно: S) мы создали файл Access DB со ссылками на все 500 списков sharePoint, затем мы реализовали пользовательский элемент управления, который имеет элемент управления просмотра отчетов. Этот пользовательский элемент управления принимает обычный запрос T-SQL для запроса к базе данных Access, база данных Access получает данные из базы данных SharePoint и передает их обратно пользовательскому элементу управления, который просматривает набор данных в средстве просмотра отчетов.

Существуют и другие проблемы, связанные с администрированием, но я бы хотел сосредоточиться здесь на разработке.

Итак, после того, как я показал вам картинку (простите за длинный пост). Как вы думаете, что было лучшим методом разработки SharePoint, который мы должны были использовать в таком ориентированном на данные проекте, если таковой имеется?

Я слышал, что некоторые компании вообще не используют списки в таких проектах и ​​создают собственные таблицы базы данных SQL вместо базы данных SharePoint. Но я не могу удержаться от мысли, что если я создаю свою собственную БД и, следовательно, внедряю свои веб-части CRUD с нуля (мы также потеряем преимущества модуля безопасности, предоставляемые списками SP), каковы будут преимущества SharePoint?

Еще раз прошу прощения за длинный пост.

Answer 1

Я не согласен с Джеффом и Абу в том, что SharePoint является плохим выбором для крупных корпоративных приложений.

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

Как разработчик, который работал с SharePoint в течение нескольких лет, многие из проектов, над которыми я работал, были выполнены по некоторым проектам, которые я сам не считал бы подходящими для SharePoint в первые несколько лет разработки на этой платформе, однако сейчас больше опыта Я знаю, как использовать возможности платформы гораздо лучше, и я понимаю преимущества, полученные с помощью SharePoint для проектов такого рода. Тем не менее, у меня есть ряд проблем с частями платформы, но это ничем не отличается от любой другой платформы, над которой я работал, включая части платформы ASP.Net.

Если бы меня попросили разработать решение с использованием системы на основе Java (или, возможно, новой платформы MVC), я уверен, что у меня возникло бы много проблем, подобных тем, с которыми вы столкнулись, когда я просто не знаю, каков будет правильный подход быть. Это ни в коем случае не будет проблемой с платформой, но больше с моей неопытностью.

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

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

Answer 2

Я думаю, вы точно узнали, что я сделал. Sharepoint просто плохо справляется с приложениями большого корпоративного типа. В итоге мы создали собственную базу данных для размещения наших данных. Мы использовали Webparts для пользовательского интерфейса, но в остальном все приложение не зависело от Sharepoint.

На мой взгляд, Microsoft перепродает Sharepoint. На самом деле он хорош для сайтов коллективной работы и простых приложений служб Excel, но ничего кроме этого просто не способен обработать.

Answer 3

Если вы ищете решение, ориентированное на данные в SharePoint, лучшим решением будет использование Каталог бизнес-данных (BDC). Это сохраняет ваши богатые отношения с данными и все необходимые вам качества SQL (или других СУБД) там, где они должны быть - в репозитории, предназначенном для оптимального хранения данных .

Обзор возможностей BDC см. В этой публикации в блоге группы разработчиков SharePoint. Для получения более подробной информации прочитайте серию в журнале SharePoint . Обратите внимание, что для этих функций требуется корпоративная лицензия SharePoint 2007.

Answer 4

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

Быть платформой не означает, что все настройки нужно выполнять на основе списков SharePoint. Поскольку он построен на ASP.NET, в SharePoint вы можете делать все, что можете в ASP.NET.

Я создал множество приложений ASP.NET, которые размещались в SharePoint, позволяя SharePoint выполнять аутентификацию и т. Д.

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