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

Эта ошибка вызывается браузером. Не может быть исправлено путем настройки кода клиентского приложения. Чтобы это исправить, вы должны заставить свой сервер узлов обрабатывать предварительный запрос OPTIONS, который запускается браузером, когда вы делаете запрос ajax в другой источник, чем веб-страница, на которой в данный момент выполняется.

Затем сервер должен ответить на это с правильными заголовками:

Access-Control-Allow-Origin: '*' или 'Access-Control-Allow-Origin': 'http://localhost:3000'

Вы можете добавить этот пакет на сервер вашего узла: [114 ] https://expressjs.com/en/resources/middleware/cors.html

Это сделает всю тяжелую работу за вас.

Если это просто для целей разработки, вы можете просто запустить Chrome с отключенной веб-безопасностью:

Mac: open -a Google\ Chrome --args --disable-web-security --user-data-dir=""

Windows: chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security

7
задан Pete Maroun 15 April 2009 в 13:14
поделиться

5 ответов

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

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

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

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

1
ответ дан 7 December 2019 в 01:26
поделиться

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

5
ответ дан 7 December 2019 в 01:26
поделиться

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

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

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

Обновление

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

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

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

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

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

3
ответ дан 7 December 2019 в 01:26
поделиться

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

1
ответ дан 7 December 2019 в 01:26
поделиться

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

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

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

http://slam.codeplex.com

Happy Slamming!

Allan

0
ответ дан 7 December 2019 в 01:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: