Коллеги,
Есть задача разработать определенное бизнес приложение. Энтерпрайз, интранет, проводки, документы и прочее. Бизнес-логика ясна, т.е. сделать это приложение на десктопе не представляет сложностей.
Проблема в том, что требуется сделать это приложение в SharePoint 2010 Server. Строго и без обсуждения. И база данных, кстати, будет отдельная. Как новичек в sharepoint'е, я пошел по пути изучения литературы и адаптации своего десктопного опыта. Множество документации о том, как сделать вебчасти и прочие кусочки и очень мало информации (или у меня гугл кривой) о том, как построить комплексное решение. Поэтому я набросал и оттестировал пробные варианты. Да, так как база данных отдельная, то во всех вариантах она закрыта слоем wcf-служб, которые хостятся на веб-сервере в пуле sharepoint'а и реализуют основную бизнес логику. Итак реализация клиента:
1. Сильверлайт-приложение запакованное в веб-часть. Т.е. развернул на любом портале и работай. Вариант, хоть и наиболее близок мне, не очень понравился.
2. Вручную нарисованные application pages. Тоже не очень понравился вариант, т.к., на мой взгляд, сложно держать проект единым целым. Плюс доступ пользователей по узлам вида bla-bla\_layout\bla-bla имеет свои, еще не до конца разобранные особенности (честно, не очень углубился тут) и выглядит не очень.
3. Прикрученный asp.net mvc 2 внутрь сайта. Вариант нравится больше всех, т.к. проект собран целиком в студии, разворачивается на сайт автоматически (правки в web.config, настройки), вполне вменяемый и тестируемый подход, вменяемые url'ы, доступ к серверному контексту sharepoint'а, авторизация от него же и т.д. Из минусов - очень смущает его неподдерживаемость и недокументированность. Единственное, что нашел в книжке Dave Milner'а - "One approach that will not mix well with the current feature set in SharePoint 2010 is the MVC templates such as a MVC 2 or 3 application. This is because the URL rewrite features in MVC are not currently compatible with SharePoint 2010’s handling of navigation and web pages. While it may be possible to integrate it, a solution of this nature has too many points of potential failure. I do not recommend this approach." И хотя я нормально настроил роутин и на портале вместе сосуществуют обычные sharepoint'овсие страницы, application pag'ы и mvc'ные динамические вьюхи, меня смущает эта фраза.
Резюмируя, я понимаю, что в отсутствии опыта и с кашей в голове далеко не уедешь, и поэтому прошу подсказать, каким образом можно реализовать "бизнес-приложение на sharepoint" так, чтобы это был отдельный проект (или пачка проектов) в visual studio, которое можно быстро развернуть на пустой портал, к которому можно прикрутить тесты, работать над которым можно нескольним сотрудника одновременно и чтобы оно работало с отдельной базой и имело доступ к серверному контексту sharepoint. Какие приняты подходы? Подойдет ли что-то из того, что я написал или бест-практикс говорит о другом?
Спасибо!

Rb-Sr,

Да, с wsp всё понятно. Я готов или использовать встроенный механизм запаковки или даже, если понадобится, паковать скриптами, составляя манифесты вручную. Вопрос не в этом.
Я понимаю, что очень неточно формулирую вопрос. Попробую объяснить.
Я не могу понять, каким образом ведется/пишется/поддерживается проект определенного решения/приложения для sharepoint. Нужно ли это делать на простых страницах? И что в этом случае, рисовать их в sharepoint designer, потом выгружать и включать в пакет студии? Визуализация страниц, как я понял в студии не работает. А как же потом их поддерживать? Каждый раз править в designer'е и выгружать?
Или принято такого рода решения делать на application page'ах? Или в сильверлайте? Или еще как?
Нам подрядчик сделал одно приложения настроив его прямо в готовом портале, настроив там все странички, конфиги, допрограммировав фичи и всякие части, встроив это все туда же, в живой портал и назвал это дистрибутивом. Мне абсолютно неприемлем такой вариант. Я понимаю, что должен быть пакет, который мы разворачиваем на ферму и получаем работающее приложение (без данных, разумеется), но не донастраивая его на production-ферме.
И я не нашел описания или примеров мало-мальски большого приложения. Как его делают, какой подход используют и как потом поддерживают?

Спасибо!

andmar_,
Отлично, спасибо!!! Личный опыт - это как раз то, что интересно больше всего. Коллеги, делитесь опытом, кто как организовывал разработку.
А от sharepoint у нас останется только название, хостинг, учетные записи, ну и может быть библиотеки документов + reporting + поиск.
Позвольте задать несколько вопросов:
1. Если делать страницы как site pages - пользователь сможет, при наличии прав разумеется, их менять. Были ли какие-нибудь проблемы с этим?
2. Кто-нибудь пробовал прикручивать asp.net mvc? Т.е., как я писал в первом посте, прикрутить получилось и всё очень понравилось, но смущает то, что mvc для sharepoint официально не поддерживается.
Спасибо!

tsyselsky,

Спасибо!