Никто же не говорит, что человек не сделает, вопрос в сроках :-) Ведь
В бизнесе ценятся не знания, а способность ставить и добиваться результата, приносить прибыль, повышать эффективность
Я говорю, что для ASP.NET MVC сделать проще и поэтому найти человека, который сделает, тоже проще. Поэтому этот человек ещё и стоить будет дешевле. И за промежуток времени сделает больше, чем человек, который делает на шарике. Профит!
Калькуляторы можно сделать по той архитектуре, которую вы признали глупой. В этом случае все преимущества настраиваемости сохраняются. Таким же способом можно настроить и поиск, ведь весь контент всё равно расположен в шарике. Не надо ничего переписывать, надо использовать существующее с умом.
Мне кажется, что вы видите во мне противника SharePoint для всех сценариев использования («шарепоинт не нужен», «шарепоинт кушает много памяти», прочее). Нет, я разработчик SharePoint. Но я за использование там, где это оправдано. Для внешних сайтов — не оправдано.
Вы так и не поняли основную мысль. Основная мысль состоит в том, что переделывать дизайн для шарепоинта — это очень трудоёмкая задача. В любом случае. Даже при наличии pulishing. В результате возникает ситуация, когда вёрстка у верстальщиков готова, но из-за того, что эту вёрстку требуется натянуть на шарепоинт, начинаются проблемы. Например, риббон пропадает. Или появляется, но кнопки в нём disabled.
Проблемы бывают и в бек-энде, но они решаемы. Но зачем, осознавая, что проблемы будут, специально идти проблемным путём, я не понимаю.
Коллеги утверждают, что сама МС рекомендует использовать подход, когда для публичного сайта SharePoint используется как бэк-энд.
ЗЫ
Вы идёте на SharePoint User Group завтра, 17 числа?
Вы видите хоть один SharePoint-контрол на сайте ВТБ24? Их нет. Вы же сами говорите, что SharePoint — это не CMS. Зачем использовать платформу для задач, для которых она не предназначена?
Оцените, если можете, трудозатраты на создание шаблона publishing-страницы из готовой вёрстки (например, главная страница ВТБ24) и свертесь, пожалуйста, с опытом ваших коллег из проекта ВТБ24. А потом посчитайте количество таких шаблонов для сайта ВТБ24. Мне кажется, что трудозатраты получатся намного выше, чем в случае разработки на ASP.NET MVC.
Библиотеки, версионирование, систему прав, ролевой доступ, масштабируемость, производительность изобретать не надо. Делаем отдельное ASP.NET MVC приложение, в котором авторизуется пользователь. Шарепоинт доверяет этому приложению и тоже пускает авторизованного пользователя к себе. В результате у нас есть шарепоинт, в котором есть библиотеки, разграничение прав и версионирование. Так как ASP.NET MVC приложение ходит в шарепоинт через веб-сервис, то на авторизованного пользователя накладываются все ограничения прав, которые вы настроите в шарике. В результате мы можем делать сайт любой сложности, и нам не надо будет преодолевать сложности, которые возникают при разработке для шарика.
От SharePoint в ВТБ24 остались лишь знаменитые калькуляторы. Без шарика сайт бы сделался быстрее (и дешевле).
Просто надо понимать, для чего шарик нужно использовать, а для чего — нет. Для публичных сайтов шарик не очень подходит. Если очень хочется сделать сайт с интеграцией с шариком, то можно попробовать использовать шарик как поставщик данных (ходить за данными в веб-сервисы шарика), но придётся заморочиться с S2S-авторизацией. В этом случае получаем возможности шарика с его списками, типами содержимого и всем остальным, а другой стороны — сайт на ASP.NET MVC (или на чём хочется), при разработке которого не требуется бороться с шарепоинтом (как это всегда происходит при разработке на шарике решений, выходящих за стандартные случаи)
С одной стороны, хочется позлорадствовать, какие, мол, у нас плохие органы, а с другой стороны, вы не можете точно знать, зачем эти самые плохие органы запрашивали персональную информацию.
Я писал сокобан в рамках программерского конкурса Caos Construction'09, но у организаторов на компе не оказалось требуемой версии дотнета, так что у меня вместо консольки был отображён диалог с ошибкой :-
Потому что
.Where()имеет оптимизации для итерирования разных типов коллекций, а .Any()— нет.Я говорю, что для ASP.NET MVC сделать проще и поэтому найти человека, который сделает, тоже проще. Поэтому этот человек ещё и стоить будет дешевле. И за промежуток времени сделает больше, чем человек, который делает на шарике. Профит!
Вы так и не поняли основную мысль. Основная мысль состоит в том, что переделывать дизайн для шарепоинта — это очень трудоёмкая задача. В любом случае. Даже при наличии pulishing. В результате возникает ситуация, когда вёрстка у верстальщиков готова, но из-за того, что эту вёрстку требуется натянуть на шарепоинт, начинаются проблемы. Например, риббон пропадает. Или появляется, но кнопки в нём disabled.
Проблемы бывают и в бек-энде, но они решаемы. Но зачем, осознавая, что проблемы будут, специально идти проблемным путём, я не понимаю.
Коллеги утверждают, что сама МС рекомендует использовать подход, когда для публичного сайта SharePoint используется как бэк-энд.
ЗЫ
Вы идёте на SharePoint User Group завтра, 17 числа?
Оцените, если можете, трудозатраты на создание шаблона publishing-страницы из готовой вёрстки (например, главная страница ВТБ24) и свертесь, пожалуйста, с опытом ваших коллег из проекта ВТБ24. А потом посчитайте количество таких шаблонов для сайта ВТБ24. Мне кажется, что трудозатраты получатся намного выше, чем в случае разработки на ASP.NET MVC.
Библиотеки, версионирование, систему прав, ролевой доступ, масштабируемость, производительность изобретать не надо. Делаем отдельное ASP.NET MVC приложение, в котором авторизуется пользователь. Шарепоинт доверяет этому приложению и тоже пускает авторизованного пользователя к себе. В результате у нас есть шарепоинт, в котором есть библиотеки, разграничение прав и версионирование. Так как ASP.NET MVC приложение ходит в шарепоинт через веб-сервис, то на авторизованного пользователя накладываются все ограничения прав, которые вы настроите в шарике. В результате мы можем делать сайт любой сложности, и нам не надо будет преодолевать сложности, которые возникают при разработке для шарика.
Просто надо понимать, для чего шарик нужно использовать, а для чего — нет. Для публичных сайтов шарик не очень подходит. Если очень хочется сделать сайт с интеграцией с шариком, то можно попробовать использовать шарик как поставщик данных (ходить за данными в веб-сервисы шарика), но придётся заморочиться с S2S-авторизацией. В этом случае получаем возможности шарика с его списками, типами содержимого и всем остальным, а другой стороны — сайт на ASP.NET MVC (или на чём хочется), при разработке которого не требуется бороться с шарепоинтом (как это всегда происходит при разработке на шарике решений, выходящих за стандартные случаи)
Как твой ниисан-жук? Извини, я не хотел про него говорить плохо :-)
Спасибо, я подумаю.