Оценка Sharepoint vs ASP.NET как платформа разработки

Question

Я оцениваю Sharepoint (не MOSS) и ASP.NET как платформу разработки для предстоящего решения для нашей команды. Мы будем разрабатывать решение для широкого (мы надеемся) развертывания в различных средах. Я определяю категории для оценки плюсов и минусов для каждого выбора платформы. Я выбрал категории, которые применимы к нашим требованиям к решению, и это повлияет на производительность разработчика/тестировщика. Может ли кто-нибудь подумать о каких-либо других категориях, которые подходят для сравнения? Можете ли вы предоставить какие-либо подробности о ваших опытах с двумя платформами в отношении какой-либо из категорий?

Некоторая другая информация, у нас есть короткий двухмесячный временной интервал для выпуска чего-то, поэтому мы уделяем приоритетное внимание функциям, когда говорим. Мы видим, что Sharepoint - это способ быстро получить что-то за дверь, одновременно используя интерфейс пользовательского интерфейса для базового пользовательского интерфейса, безопасности и библиотек списков и документов для хранения.

среда разработки

Производительность Разработчик

Функциональная Тестируемость

Разработчик Тестируемость (блок-тестирование)

Role Based Security

Посмотреть на основе безопасности

Пользовательский опыт

База данных - Простота разработки с помощью Sharepoint на основе использования списков. Однако добавление отчетности в качестве требования делает использование списков препятствием.

Reporting - Sharepoint делает этот трудный

Document Repository - Наше решение потребует несколько библиотек документов для прикрепления артефактов элементов решения

Упаковка

Установки - Sharepoint предоставляет нам с легкой установкой famr через П ,

Масштабируемость

расширяемость

Сложность

концептуальную целостность (доменные границы)

Избыточность/Replication/Резервное копирование/восстановление Поддержка

Answer 1

Официально, для того, чтобы разрабатывать решения WSS, всем разработчикам необходимо, чтобы их среда разработки выполняла на сервере WSS. Я считаю это негативным.

Просмотреть комментарии от Sharepoint tools support in Visual Studio от Somasegar.

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

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

Answer 2

Я не вижу стоимости.

Answer 3

Ваше решение будет иметь какое-либо отношение к сотрудничеству или управлению веб-контентом? Если нет, добавление SharePoint в микс не будет отличной идеей.

Использование WSS 3.0 в качестве платформы разработки вместо ASP.NET потребует серьезного обоснования, и из вашего ограниченного описания вашего решения невозможно сказать, почему вы даже созерцаете это.

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

Update

Я вижу Sharepoint безопасности, библиотеки документов, рамки пользовательского интерфейса, и отсутствие необходимости строить и тест БД, как большой productivty энхансеры. Это Sharepoint особенность, которые мы можем извлечь большую пользу из

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

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

Не зная подробностей проекта, я не могу полностью исключить SharePoint как решение.

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

Answer 4

Масштабируемость
Ограничения лицензии
расширяемости
Сложность
концептуальную целостность (доменные границы)
Vendor впадения/Открытые системы Поддержка
Избыточность/Replication/Резервное копирование/восстановление Поддержка

Answer 5

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

Мы разработали SLAM, Manager List List Manager, чтобы преодолеть очевидные ограничения в отношении того, что данные SharePoint не являются реляционными. Поскольку он подталкивает данные SharePoint к SQL Server, он позволяет использовать SharePoint только на «бэкэнд» только с ASP.NET на передней панели, часто используемой нами конфигурацией.

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

http://slam.codeplex.com

Днем захлопывания!

Allan