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

Question

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

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

Поддержка резервирования / репликации / резервного копирования / восстановления

Answer 1

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

Answer 2

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

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

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

Обновление

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

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

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

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

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

Answer 3

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

См. Множество комментариев в разделе Поддержка инструментов Sharepoint в Visual Studio от Somasegar.

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

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

Answer 4

Масштабируемость
Лицензионные ограничения
Расширяемость
Сложность
Концептуальная целостность (границы домена)
Поставщик Lockin / Поддержка открытых систем
Поддержка резервирования / репликации / резервного копирования / восстановления

Answer 5

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

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

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

http://slam.codeplex.com

Счастливого хлопка!

Allan