Переход от пользовательского приложения ASP.NET к Sharepoint Services

Question

Наша компания имеет приложение ASP.NET для базы данных о клиентах. Приложение началось с малого, но выросло без надлежащего дизайна. Теперь следует разработать новую версию приложения, что в основном будет означать разработку и реализацию с нуля. Компания заинтересована в использовании Microsoft Sharepoint Services в будущем, и было предложено опробовать ее с этим приложением базы данных клиентов.

Итак, мои вопросы:

Является ли приложение, управляемое базой данных, полезным для WSS? В основном приложение будет выполнять CRUD-операции с базой данных, а также создавать отчеты.

Answer 1

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

Вот длинный ответ ...

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

Вы могли бы рассмотреть BDC для чтения / извлечения данных, но это требует MOSS Enterprise и не предоставляет CUD часть CRUD. Могут помочь другие инструменты, такие как CorasWorks DIT, но я подозреваю, что для вас стоит использовать собственные веб-части или страницы.

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

Answer 2

Краткий ответ: Нет.

Длинный ответ: Есть ли сотрудничество? Подтверждающая документация для данных? Рабочий процесс? Если нет, то на самом деле нет никаких оснований для его размещения через SharePoint - вы не получите много.

Кроме того, имейте в виду, что списки SharePoint могут выглядеть как таблицы, но это не так - есть нет реляционных аспектов списков - нет объединения, нет каскадных обновлений / удаляет и т. д. Это может быть проблемой, если отчеты о данных являются важной частью вашего приложения.

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

Answer 3

Кирк избил меня до удара и сказал это лучше, чем я бы все равно:)

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

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

Создание SP для использования SP, вероятно, не очень хорошая идея.

Answer 4

У нас есть приложение ASP.NET, которое запускается в MOSS 2007. Хотя мы практически не используем какие-либо функции SharePoint, мы получаем преимущество от модели безопасности SharePoint, веб-частей навигации (мы используем CorasWorks), интегрированных служб отчетов и рабочих процессов. По крайней мере, когда-нибудь мы сможем использовать функции SharePoint.

Все данные нашего приложения находятся в собственной базе данных SQL Server. Мы ничего не храним в базе данных контента SharePoint.