WSS 3.0 как платформа приложений

Question

Это архитектурный вопрос.

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

Мой вопрос заключается в том, следует ли нам предоставлять WSS клиенту для внешней обработки или создавать стандартное приложение ASP.NET с использованием WSS на уровне приложений и позволить приложению ASP.NET взаимодействовать с WSS с помощью API-интерфейса WSS / веб-службы. Легко настроить приложение ASP.NET без внесения каких-либо изменений в WSS. Внутренним пользователям не требуется никакой маркировки, и, следовательно, они могут перейти на внутренний WSS-сайт для выполнения операций рабочего процесса. С тех пор, как я начал разработку WSS, создание новых возможностей и продвижение к бренду стало сложной задачей.

Пожалуйста, дайте мне знать ваши мысли.

Answer 1

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

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

Взгляните на такие инструменты, как VSeWSS или WSPBuilder, чтобы упростить разработку WSS 3.0 (если вы используете Visual Studio), и воспользуйтесь SharePoint Designer там, где это необходимо.

Answer 2

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

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

Потребовалось бы очень сильное требование в области ИС или финансов, чтобы заставить меня рассмотреть вопрос об упаковке asp.net поверх WSS.

Я работал с решением, которое делает это, и оно работает для нашего внешнего сайта, но это кобыла обслуживания.

Answer 3

Если вы не много знаете о SharePoint, создание и представление пользовательского интерфейса будет затруднено.Ты можешь сделать это?Абсолютно.Должны ли вы сделать это?Это зависит от ваших требований и уровня вашего опыта работы с SharePoint.На мой взгляд, самый простой путь - создать приложение ASP.NET и иметь такой интерфейс с SharePoint, но я трачу 90% своего рабочего дня на работу с ASP.NET и занимаюсь разработкой SharePoint только раз в год.

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