Ошибка в SharePoint'е может возникнуть абсолютно в любом месте. В самом неожиданном! Самые безобидные действия могут повлечь за собой ужасающие последствия...
Например, однажды я сбросил наследование разрешений у интернет-сайта на продакшене. Три часа потения и седых волос было обеспечено: полностью пропала навигация на этом и вложенных сайтах (а вложенных сайтов было 50 штук)... И возвращаться отказывалась.
Другой пример: если добавить комментарии в Content Type Definition, из типа содержимого начинают магическим образом пропадать поля :) CAML в SharePoint вообще капризный и неудобный: именно поэтому я так люблю использовать T4 шаблоны для его генерации.
Сколько угодно таких вот странностей...
А решения! Решения проблем - это просто потрясающе. Ставим SP 2013 на Domain Controller, и Sandboxed Solutions не работают... Никогда не угадаете, какое решение. Включить Verbose Logging!! Как только включаешь Verbose Logging, все начинает работать. Какая связь? :)
Как можно кого-то в SharePoint называть косячниками!?! :)
Про тестирование
Вы скажете, дак тестировать же надо! Согласен. Тестировать надо, и это безусловно снижает количество ошибок. Но...
Помню, долго-долго пытался найти способ использовать XslLink в Sandboxed Solutions. Было очень много попыток, и после одной из попыток остались артефакты - не была удалена папка фичи. В итоге я пришел к ложным выводам, опубликовал по этому поводу радостный пост, и был на самом деле очень-очень расстроен и пристыжен, когда выяснилось что все это не правда :( Дотестировался. Epic fail.
Проблемы связанные с кешем очень гадкие. Причем единственный по-настоящему надежный способ сбросить кэш - это откатить виртуалку...
В другой раз публиковал про разбиение формы на вкладки. В итоге, как потом выяснилось (уже после публикации), в некоторых случаях форма сохраняться перестала :( Обидно: тратишь на исследование несколько часов, а то и дней. Вышлифовываешь все ну просто до блеска. Итог... плачевный.
И я даже не упоминаю о том, что как бы вы хорошо не тестировали свое решение, но на production всё будет по-другому.
Складывается такое впечатление, что даже после очень плотного тестирования, вероятность ошибки сохраняется очень большая. С учетом того, сколько на тестирование уходит времени, всесторонее тестирование, включая автоматизированное, решений на SharePoint уже не выглядит особенно привлекательным процессом :(
Внешний мир
С другой стороны, если взглянуть во "внешний мир"...
Участвовал в четырехмесячном проекте на ASP.Net в прошлом году. Полный кайф! Десятки миллионов записей в таблице - никаких проблем, прямые запросы, банальный MS SQL. Возникла проблема с производительностью, лениво тыкаешь кнопочку профайлера в студии, через 3 минуты перед тобой подсвеченная красным проблемная строка...
AngularJs, Single-Page-Application, ASP.Net Web API, EF Code First... Очень классно! Очень здорово! Для всего есть библиотечки, все библиотечки очень удобно подтягиваются через NuGet, замечательные современно выглядящие интерфейсы, красивые и динамические, и все очень быстро! Я потом вернулся в SharePoint и полдня пытался найти проблему, из-за чего же у меня сайт тормозит... оказывается, просто отвык: это была нормальная скорость SP :)
SharePoint Apps
Но с другой стороны, давайте теперь подумаем про Apps. Вот многие ругают модель SharePoint Apps. В последнее время, однако, мне кажется, что не надо: ведь это классный способ переключиться на весь этот замечательный стек новых технологий, и максимально отвязаться от проблем и ошибок SharePoint, при этом оставшись в "маркетинговой струе" MS.
И это совсем не означает меньше денег. Это скорее означает больше пользы, за те же деньги :)
I, for one, chose alternative path: try to distance myself from Microsoft stack of technologies as far away as possible and learn completely different things (Java, Linux, Android, open source community-driven software, Arduino). Then in a 1.5-2 years I'll see what will happen to SharePoint and other MS things, and if their state at that moment will satisfy me, I'll think of getting back into MS's arms wide open :)
ОтветитьУдалитьПро sandbox это конечно шедевр ))). У меня, например, другая ситуация: бесконечно плодящиеся процессы SPUCWorkerProcessProxy.exe. Уже несколько раз пробовал подходить к решению этой проблемы и все никак она не поддается. Процессы плодятся и съедают всю память сервера. Может сталкивался? Конфигурация такая же all-in-one server.
ОтветитьУдалитьЧто касается apps: я так понимаю, более популярны sharepoint-hosted и provider-hosted (эти ни разу не пробовал, интересно бы посмотреть на живой пример). В прошлом году пробовали начинать проект на apps, но не устроило вот что: (1) только клиентский код на js (как потом выяснилось и на C# и на любом другом языке теоретически можно) и (2) нужно весь GUI рисовать самому. Если пункт 2 еще катит во многих случаях (все равно брендинг делают), то пункт 1 стал камнем преткновения: у CSOM казалось возможностей меньше (а документации то толком не было), особенно после 2010 версии, не до конца понятный и не прозрачный процесс создания provider-hosted apps. Чего там стоит только правильная настройка аутентификации. Все эти минусы "добивали" уже имевших дело с sharepoint разработчиков и вызывали отвращение. Обычно мысли были такие: "Да ну их нафиг с их нововведениями, вернусь ка я к старым добрым farm solutions". Посмотрим, как дело пойдет дальше. С тех пор ситуация все таки изменилась в лучшую сторону: CSOM API сейчас позволяет делать очень многие вещи, да о опыта прибавилось в работе с ним, сегодня есть куча js фреймворков для достаточно быстрого построения GUI: knockoutjs, angularjs, есть библиотеки для SPA, для удобной работы с RestAPI, даже для CSOM API уже кто то сделал ShareCoffee (не пробовал). В общем apps позволяют применить огромные наработки мирового сообщества по части js библиотек проще чем это было без них. Правда и тут не обошлось без Microsoft way )). Я про TypeScript. Задумка отличная, но на все библиотеки в мире дефинишенов нет )). И тут либо пиши на js, либо трать время на написание дефинишенов (в этом конечно есть свой плюс - разбираешься с библиотекой), а хотелось бы все таки решать задачу а не писать дефинишены.
Я так думаю, что SharePoint разработчик может без особого труда уйти во "внешний мир", если захочется. Я сейчас не говорю про совсем неродственные ms технологии, я говорю про чистый ASP.NET, SQL и т.д. Все дело в желании. У меня тоже порой возникают ощущения, что разработка под SharePoint - это точно не про скорость. Хотя по сути идея существования таких платформ - это ускорение разработки.
>>Процессы плодятся и съедают всю память сервера. Может сталкивался?
Удалитьнеа :(
>>(1) только клиентский код на js и (2) нужно весь GUI рисовать самому
оба пункта в общем-то неверны :)
>>Чего там стоит только правильная настройка аутентификации
ничего не стоит. скачиваешь готовый проект из инета и используешь. я до сих пор понятия не имею как там эта аутентификация работает.
>>ShareCoffee
и SPTypeScript!
>>но на все библиотеки в мире дефинишенов нет
есть. см. https://github.com/borisyankov/DefinitelyTyped
>>может без особого труда уйти во "внешний мир", если захочется
иллюзия. SharePoint безнадежно устарел, а web-разработка за последние 3 года так сильно рванула вперед, что догонять довольно долго. ASP.Net уже совсем не тот, ты что! блин, там в markup репитеров можно брейкпойнты ставить. блин... там стока новых фич... по сути все заново учить.
>>разработка под SharePoint - это точно не про скорость
5 лет назад я перешел с ASP.Net на SharePoint и я был в восторге, потому что на SharePoint было разрабатывать намного быстрее и проще. к сожалению, за 5 лет SP превратился в болото, а ASP.Net - наоборот, рванул вперед немыслимыми темпами.
>>>>(1) только клиентский код на js и (2) нужно весь GUI рисовать самому
Удалить>>оба пункта в общем-то неверны :)
Я написал ниже в том посте: "(как потом выяснилось и на C# и на любом другом языке теоретически можно) ". А насчет пункта 2: каким образом можно в аппсах заюзать native gui?
>>ничего не стоит. скачиваешь готовый проект из инета и используешь
если ты пробовал - спорить не буду, я не пробовал ))). Только слышал мнение других.
>>>>но на все библиотеки в мире дефинишенов нет
>>есть. см. https://github.com/borisyankov/DefinitelyTyped
Давай не будем лукавить. DefinitelyTyped это только малая часть, сегодня js библиотеки выходят чуть ли не каждую неделю, фреймворки - каждый месяц если не чаще. Я не спорю о преимуществах typescript, они очевидны.
>> лет назад я перешел с ASP.Net на SharePoint и я был в восторге,
А теперь думаешь вернуться обратно?
>>каким образом можно в аппсах заюзать native gui?
Удалитьв apps'ах есть Client chrome control, который рисует базу. а дальше - как всегда: списки, веб-части, все это можно деплоить на app web без ограничений. обобщая, рисовать в apps'ах нужно ничуть не больше, чем в самом SP...
>>DefinitelyTyped это только малая часть
сколько либ не юзал, все там есть. самые распространенные - есть точно. блин, их даже пересчитать невозможно уже, их там под сотню как минимум...
>>думаешь вернуться обратно?
ну а что, приятно сидеть в болоте, позади планеты вся? :( но теперь вот видишь, даже возвращаться никуда не требуется. рекомендованный MS переход на provider-hosted apps в целом почти аналогичен возвращению в pure ASP.Net :)
>>рекомендованный MS переход на provider-hosted apps в целом почти аналогичен возвращению в pure ASP.Net :)
Удалитьсогласен
на твой взгляд меняется ли что то для заказчика - будет проект сделан на "классике" или на новых аппсах? Для разработчика?
меняется для обоих. и мне кажется, к лучшему, как минимум в долгосрочной перспективе.
Удалитьдля заказчика:
- эстимейты для pure ASP.Net делать гораздо проще и они намного точнее - как следствие, имеем более предсказуемые сроки окончания работ
- решения, основанные на современных фреймворках, хорошо выглядят, ими приятно пользоваться
- работа с большими объемами данных - совсем не проблема
для разработчиков:
- становишься более универсальным, открываются новые карьерные перспективы, т.к. работаешь по сути в основном с универсальными веб-технологиями, не завязанными напрямую на SharePoint
- больше мотивация, и больше удовлетворение от работы, потому что работаешь со всем новым, и работаешь над решением реальных проблем, а не копаясь в кишках SP
и еще, для разработчиком, меньше шансов сломать продакшн безобидным щелчком мыши! :D
Удалить>>>>Чего там стоит только правильная настройка аутентификации
Удалить>>ничего не стоит. скачиваешь готовый проект из инета и используешь. я до сих пор понятия не имею как там эта >>аутентификация работает.
Все не так радужно. Готовый проект из инета не работает. При этом я взял не просто "какой нибудь" проект, а проекты из Office 365 Developer Patterns & Practices (https://github.com/OfficeDev/PnP). Брал те - которые работают с on-premise. Ничего не вышло. Судя по по ошибкам - проблемы с аутентификацией аппа.
Ладно, попробовал сделать свой provider hosted app. Минут 20-30 потратил на настройку S2S trust authentication. Настроил. В итоге remote web валится с NullReferenceException в коде, который студия сгенерила автоматически (TokenHelper.cs).
А ты говоришь все просто, там до "все просто" еще очень далеко на мой взгляд.
Насколько помню шаблон для консольки брал у Wictor Wilen. В provider hosted app у меня все без проблем, вчера создавал, в o365 логинится замечательно.
УдалитьДля o365 используется OAuth, я же использую S2S trusts. Посмотрел пример Wictor Wilen, попробовал - все равно не работает. NullReferenceException в методе TokenHelper.IssueToken.
УдалитьЗаработало только если app делать на самом сервере sharepoint. С клиентской машины ни в какую не хочет.
УдалитьДа, еще. Андрей, ты упомянул об использовании T4 для генерации CAML запросов. Чем конкретно ты пользуешься, какими либами? Можешь показать пример? Или ты для своих запросов написал шаблоны а потом юзаешь их?
ОтветитьУдалитьне, не CAML запросов. для CAML запросов есть camljs.
Удалитья говорил про CAML вообще.
ну да иногда пишу банальные T4 шаблоны, иногда кодом генерю. T4 тоже не блещет, на самом деле :( но им хотя бы склеивать и размножать удобно.
например, представь у тебя есть кусок XML, который что-то делает. тебе надо создать такой же кусок и изменить там буквально пару параметров. вот в таких случаях юзаю T4 вместо копипаста.
camljs это только на клиенте (((. Кстати довольно удобно, я теперь только им пользуюсь если нужно caml написать. Спасибо за библиотеку!
УдалитьСпасибо за отзыв. Надеюсь в сентябре выпустить новую версию camljs. Самая революционная идея для новой версии - это camljs-дев-консоль, типа как CAML Query Builder, только интегрированная в браузер :)
УдалитьЭто типа чтобы накликать можно было запрос?
УдалитьНе то чтобы накликать. Скорее сразу же протестить. Data preview.
УдалитьАндрей, давно читаю твой блог, иногда вижу твою активность на sharepoint stackexchange. Тема про "внешний мир" меня зацепила).
ОтветитьУдалитьСейчас делаю проект на провайдер хостед аппсах, узнал кучу всего нового, Web API, angular, azure и много трудого, все просто безумно интересно изучать и пробовать,
в начале проекта понял, насколько я отстал от "обычного" мира разработки. Согласен на счет "болота" под названием шарепоинт...
Мне интересно твое мнение, ты как опытный шарепоинт разработчик, как думаешь, имеет ли смысл дальше увязать в "болоте" или забить и заниматься интересными вещами, по которым больше документации,
у которых больше поддержка комьюнити, которые динмачно развиваются и которые меньше глючат? Если в общем, есть ли будущее у разработчика под шарепоинт?
Kai, SharePoint-разработчикам в России, насколько мне известно, хорошо платят. Это немаловажно :)
УдалитьКроме того, как показывает и мой и, как оказывается, твой собственный опыт, у SharePoint есть весьма светлое будущее в виде provider-hosted apps :) И очень здорово, что MS рекомендует использовать именно их для любых кастомизаций. Получается, что это официальное будущее SP-разработки.
Поэтому, мне кажется, у SharePoint-разработчика вполне себе есть будущее.
С другой стороны, надо понимать, что еще какое-то время проекты будут преимущественно классические, без apps.
Коллеги, тогда возникает такой вопрос: в контексте sharepoint provider hosted apps, какие именно плюсы дает наличие лпатформы sharepoint? Если все движется в сторону pure ASP.NET, использования широко известных js библиотек да и просто множества ASP.NET библиотек то почему разработчику должно быть выгодно/интересно продолжать выбирать в качестве платформы sharepoint apps, когда он может использовать современный ASP.NET и создавать в более короткие сроки более стабильные решения?
УдалитьКакие на ваш взгляд сценарии лучше "укладываются" в sharepoint apps и при этом их сложнее/дороже "уложить" в modern ASP.NET? Я в данном случае имею в виду разработку. Понятно, что "клепать" типовые корпоративные порталы можно практически без программирования и с этим sharepoint лучше справится. Меня интересует вопрос именно в контексте разработки.
Смысл вот в чем. MS рекламирует и продает SharePoint. Создан пул SharePoint-клиентов. И эти клиенты, они хотят дополнительную фичу для своего портала, а не новый отдельный сайт. Они банально не будут даже заказывать ASP.Net-разработку. Так что тут даже никаких вариантов нет.
УдалитьДругой вопрос, что в случае provider-hosted apps, при желании, в основном можно писать на pure ASP.Net.
С технической точки зрения, SharePoint предоставляет:
1. саму технологию Apps
2. общую аутентификацию, свою делать не надо
3. возможности для интеграции с основным порталом, если эта интеграция нужна - а она будет нужна, никуда не денется
Другими словами, всем существующим клиентам MS, которые "сидят" на платформе SharePoint выгоднее заказывать доработки, которые скорее всего в ближайшем будущем в большинстве случаев будут выполняться в рамках идеологии apps, чем нанимать pure ASP.NET разработчика. Тут сложно поспорить.
УдалитьНо что делать заказчику, который еще не выбрал платформу? Какие для него плюсы в SharePoint? К нему в очереди будут стоять команды pure ASP.NET разработчиков предлагая решить его задачу зачастую более эффективно, более быстро и вероятно дешевле. Я могу понять выгоду, которую "предоставлял" SharePoint 5 лет назад, но сейчас? А если эти рассуждения верны, то притока новых клиентов не будет и SharePoint для MS превращается в "дойную корову", которая просто будет приносить деньги еще какое то время. А что будет потом? Продукт окажется никому не нужным, развития не будет. Для разработчика с точки зрения финансовой это может и неплохо, поддерживать то написанные за столько лет решения кому то надо, И делать это будут "старые" разработчики, которых будет с каждым годом меньше и зарплаты которых будут с каждым годом выше ))). Но с точки зрения собственного развития как разработчика выходит, что это путь в никуда?
>> в очереди будут стоять команды pure ASP.NET разработчиков
Удалитьи в итоге MS пройдет без очереди и пронесет SharePoint :D
ты конечно мрачно нарисовал, но:
1. нельзя недооценивать силу маркетинга MS.
2. выход-то уже нашли и вовсю внедряют. Вива, provider hosted apps! Все проблемы сразу уходят.
>>с точки зрения собственного развития как разработчика
мы вроде уже обсудили, что для разработчиков apps увеличивают мотивацию, удовлетворенность работой и открывают новые перспективы в карьере.
а если смотреть на этот вопрос с глубокой точки зрения, т.е. в чем вообще смысл "собственного развития разработчика", то я готов это обсудить, но непублично :)
На счет provider-hosted еще хотел бы мнением поделиться. Я полностью согласен, что они позволяют шарепоинт разработчику погрузиться в современный мир инструментов для разработки, прокачать знания и тд, и это классно. Но другой стороны меня сильно огорчает тот факт, что из шарепоинт разработчика (если утрировать) ты превращаешься в потребителя REST сервисов. И огромный багаж знаний по администрированию, настройке, фарм кастомизациям (ночи в попытках заставить работать профайл синхронизхацию, отбитая об стену голова после попыток понять ошибку на проде и многое многое другое)
ОтветитьУдалитьстановится не нужен. Это огорчает, понятие "шарепоинт разработчик" трансоформируется в нечто другое, но с тем чем оно было общего становится все меньше :) По сути, многие enterprise продукты предоставляют rest api, можно прокачать этот апи и называть себя sap (возможно плохой пример) разработчиком и в таком духе, хотя чтобы изучить сап нужно не меньше года.
Багаж знаний да, и это кстати главная причина сопротивления комьюнити к приходу apps. Потому что кучу знаний и опыта просто выбрасываешь в ведро.
УдалитьНо такова се ля ви. Это на самом деле происходит абсолютно везде в той или иной степени. Опыт устаревает. Собственно поэтому и возникает парадигма "вечного обучения новым технологиям".
Вечного, потому что еще три года назад AngularJs никто не юзал. Т.е. все юзали что-то другое. Сейчас Angular - мейнстрим. Значит, он что-то заместил, какие-то знания устарели. Завтра и Angular устареет. И его заменит например Meteor. И все эти знания по Angular устареют, и люди их выкинут в помойку.
Это мы в SharePoint избаловались. Backwards compatibility, все дела. Во "внешнем мире" все жестче. Нет времени для compatibility. Была либа, нету либы. Какая еще либа? Хуже. Был язык, нету языка. Перл? Что такое перл?
Прям больное :(
ОтветитьУдалитьЯ аппс видел только в теории и тяжко себе представляю как с ним дружить. но первая мысль была, а причем тут шарик?, и не профакпил ли я свое время, свои 7 лет на борьбу с шедеврами индуского соплястроения?? считаю, что профакапил! но не совсем! и успокоился я вот на таком подходе:
1. Если решение не упирается в ограничения шарика, то его делаем на шарике.
Тем более у шарика есть своя ниша, которая отлично работает из коробки или с минимальной кастомизацией, например файловая помойка проекта/команды, версионность, совместное редактирование onenote, Word, узел проекта с wiki движком для обобщенной инфы и т.п. прелестями из коробки.
2. Если решение упирается в ограничения шарика, то делаем его на аппс.
При этом, MS уже все, более менее, крупные конторы подсадил на шарик 2010, и на 2013 они переходит не спешат. Скоро уже 2015 год, а мы проектов под шарик 2013 пока и не видали.
И еще не маловажный момент, существует ряд типовых решений, например согласовалка разного рода заявок, которые отличаются друг от друга набором полей в форме, логикой согласования, наличие или отсутствием отчетов, требованием хранить где то файлы и т.п. и кучей еще всякого рода требований, под каждое из которых, временами, нужен целый модуль стоимостью в года 3 работы, и как прикажите эту кучу решений внедрять? Клипать кучу разных сайтов? Или использовать некую платформу? Если некую платформу, ТО КАКУЮ?
Вначале я переживал и думал, что за 7 лет потраченного на шарик времени, у меня бы уже был некий движок для решения тех задач, какие я решаю сейчас на шарике, и работало бы это в разу лучше, шустрее, и стоило бы дешевле и т.п. но! Быть оно может и было бы, но повторить или даже приблизиться к ряду фишек что есть в шарике я бы не смог ни когда, к этому можно отнести:
1. В принципе не плохая «файловая помойка», которая «дружит» с MS Office. попробуйте ка ее заменить.
2. Какая ни какая ORM, которая настраивается мышкой, С ограничениями, но все же список за 5 минут это реальность, по элементное разграничение прав, корозина и т.п.
3. Наличие дизайнеров , например для РП, или форм Инфпас, отчетов.
4. Собственно сам CMS, Хоть и кривой канешна, Но аутентификация есть, навигация есть, админка и т.п.
И если выбирать платформу, то я конечно же выберу шарик и все что мне осталось, это научится писать аппсы и догонять внешний мир.
Александр, очень важно понимать, что сейчас написаны миллионы опенсурс библиотек. На любой вкус, что угодно. И очень высокого качества. Не надо писать что-то с нуля. Все собирается из библиотек словно из блоков. Причем либы подтягиваются через Nuget, что очень приятно: это быстро, удобно, 10 секунд и либа у тебя в проекте. Не понравилась - 10 секунд и ее нет.
УдалитьА касательно шариковских "незаменимых" фишек, скажу вот что:
1. Файловая помойка с интеграцией в офис это ключевая фича шарепойнт я думаю. Но сделана она откровенно плохо, если смотреть правде в глаза. Большая половина фич не используется, а если используется, то утыкаешься в миллион ограничений. То нельзя, это нельзя, то не работает, это глючит.
2. Александр, попробуй EF CodeFirst :) Просто попробуй. Это совершенная магия по сравнению с шарепойнтовскими списками. UI к этому делается тоже элементарно или на webapi+angular, или на встроенных средствах MVC например - да много вариантов.
3. Рабочие процессы - какашка; и дизайнер там такой что все все равно юзают Nintex. Infopath формы официально вымерли, вместе с самим InfoPath.
4. Ну дак это везде есть... В голом ASP.Net даже такое есть, а уж что говорить про CMSки. И настроить какой-нить OAuth в шарепойнте в разы тяжелее чем в том же ASP.Net.
Еще, насчет SP2010. Многие люди без всяких apps давно разрабатывают на чистом ASP.Net под шарик. Код + вебчасти, и всех делов. В Apps в общем ничего нет такого особенного-то. Наоборот, они довольно сильно изолированы от SharePoint, и в этом и есть их главная идея.
Удалитьчета прям ваще негатив. как то мы адаптировались и не че так себя на шарике чувствуем, не без мата канешна (чтоб индусы и покрывающий их МС в аду горели вечно), и решения вроде нормальные такие, и ИП и РП стандартные юзаем , решения в основном на штат функе + немного своих компонент и я бы не сказал, что решения хреновые - лично мне все мои последние решения нравятся.
Удалитьеще заметил, что к сожалению, каждый раз, когда приходится писать какой то компонент в VS, это стоит очень и очень не дешево. вообще решение на чистом ASP.NET / MVC - по факту дороже и дольше, чем аналогичное на шарике. так что с использованием apps вижу только удорожание разработки как таковой, + еще интеграцией с шариком заниматься (а интеграция хоть чего хоть с чем всегда не дешево), + тут великолепные ограничения CSOM и короче апсы будут на порядок дороже, чем чистый шарик, или чистый MVC.
как то вот так вот МС нам поднасрал. (хотя чей это поднасрал-то, хошь на чистом сиди, хошь на апсах)
правда в каждом проекте на шарике, от 20 до 40% - это борьба с индускими соплями, вот это больше всего убивает, и то решение дешевле и быстрее, чем на аналогичное на чистом MVC.
может народ подскажет какой движок на MVC , как альтернативу шарику, что бы бэкграунд на вроде аутентификации, навигации, ORM, wf движок, движок отчетов, наличие веб-сервисов и т.п. самому не писать и еще что бы это было между собой было согласовано ?
Нет никакого негатива про SharePoint, неправда. 5 лет назад он был намного лучше ASP.Net, просто за это время он не сильно улучшился: остался примерно таким же. А вот современная веб-разработка рванула так, что держись.
УдалитьАлександр, я повторюсь, если писать все с нуля, конечно будет дорого на MVC и на чем угодно. Но все уже написано. Используйте opensource библиотеки, их полно и они очень высокого качества. Мы делали очень сложное решение на pure ASP.Net, реально очень сложное. Сложные вычисления, планирование, распределение ресурсов, график рабочих смен, работа с большими объемами данных - таблицы по 20 млн. строк, real-time мониторинг, отчеты, мессаджинг, интеграция со сторонними приложениями, распределенные приложения, геймификация. И всё это уложилось в 4 месяца. И получилось приложение такого качества, которое шарепойнту и не снилось...
Андрей, был бы рад Вам если бы у вас появился пост, про описанное выше решение, с указанием какие готовые компоненты, модули вы использовали.
УдалитьАлександр, пост писать не буду, во-первых и писать нечего - все элементарно просто, во-вторых блог все-таки про шарепойнт.
УдалитьНа сервере мы использовали ASP.Net WebForms. EF CodeFirst для работы с БД, AutoMapper как вспомогательное средство для MVVM, и ASP.Net Web API + OData для отгрузки ViewModel-ей на клиент. Для юнит-тестов использовался Moq.
На клиенте - AngularJs, FontAwesome и Sass.
Это основное приложение.
Плюс было клиентское приложение для мобильных клиентов, в общем примерно с той же самой архитектурой, просто браузер обертывался в app.
Основная сложность была в том, что была сложная модель данных и мозговзрывательная бизнес-логика. Первый месяц мы практически только просто врубались в то что там вообще происходит и придумывали вместе с клиентом интерфейсы, чтобы были удобные интерфейсы и чтобы в системе было удобно работать.
УдалитьЭто было нелегко. Никакими стандартными формами аля SharePoint там и близко не пахло. Сложные дашбоарды для распределения ресурсов. Ресурсами были 200 человек, поделенные на группы и работавшие в 2 смены. Естественно эти люди также ходили в отпуск, болели и брали отгулы. Все это нужно было быстро и эффективно создавать и отображать. В итоге разметка смен напоминала рисование: все получилось наглядно и удобно. Но если вы знакомы с проблемой составления расписаний, то вы должны понимать что такая задача она ОЧЕНЬ непростая на самом деле, там куча тонкостей.
Затем собственно работа - мониторился в real-time весь процесс, прогресс выполнения задач и т.д. Специфика работы была такова, что если кто-то заболевал или по другой причине не выходил на работу, нужно было срочно заменять этого человека на другого. У всех людей был разный опыт работы на разных постах и нужно было выбрать наилучшие замены. Тут начинались сложнейшие расчеты, с вовлечением огромного количества данных.
Также система подсчитывала количество рабочего времени, составляла отчеты, позволяла распечатывать графики смен и многое многое другое.
Ну и т.д. Я не вправе рассказывать много про это, особенно публично, но я думаю итак понятно: система масштабная и сложная. При наличии 4 месяцев на все про все, бороться с косяками платформы было просто некогда. Большую часть времени я занимался бизнес-логикой, логикой расчетов и т.п. Это честно очень не похоже на шарепойнт разработку, где 90% времени тратишь, чтобы сделать какую-то полную банальщину...
Андрей, к сожалению, CSOM, JSOM, Rest API сильно проигрывают Server OM по наличию фич. В Apps почти нет визуальных компонентов, приходится рисовать их с нуля, что требует дополнительых трудозатрат, да и реализовывать UX один в один как в SharePoint не целесобразно. В результате App UX будет отличаться от родного SharePoint UX, вызывая негодование и недовольство у конечных пользователей.
ОтветитьУдалитьВам уже приходилось с таким сталкиваться и как Вы решали подобную проблему?
>>Андрей, к сожалению, CSOM, JSOM, Rest API сильно проигрывают Server OM по наличию фич
УдалитьАлександр, ну а вся идея поста как раз в том, что и не надо туда глубоко лезть. Там все плохо, мы это и так знаем :) Фичи шарепойнта, они в большинстве очень кривые, бажные и ограниченные, к сожалению.
Я пять лет решал задачи исключительно основываясь на шарепойнтовских фичах, пять лет копался в кишках шарепойнта, и кстати помимо 8 часов на работе - еще и дома, порой по столько же. Сложно писать на шарепойнте, можно - да, но сложно. Банальнейшие задачи, на решение убиваешь по несколько дней - это неприятно.
Сейчас MS говорит нам прямым текстом: не надо глубоко лезть в шарепойнт. Нужно начать воспринимать шарепойнт как продукт. Сравните с Facebook. Facebook - это продукт. И в нем есть Apps. И это всё что можно с ним делать. Вот MS говорит, что нужно SharePoint воспринимать также. Как продукт.
Если мы начнем это делать, мы развяжем команде разработки SP руки. Они почему так отстали от всего мира? Потому что все эти Server API поддерживать надо. Невозможно что-то просто выкинуть, ведь backwards compatibility же. Сколько на это уходит сил, я боюсь предположить.
>> отличаться от родного SharePoint UX, вызывая негодование и недовольство у конечных пользователей.
Как вы умудрились сделать интерфейсы, которые ХУЖЕ шарепойнтовских!?!?! наймите дизайнера интерфейсов и проблема отпадет
>>В Apps почти нет визуальных компонентов, приходится рисовать их с нуля
Странный миф. Мы уже обсуждали это выше с Андреем Тарутиным. Мой ответ был примерно такой, и он не изменился:
в apps'ах есть Client chrome control, который рисует базу. а дальше - как всегда: списки, веб-части, все это можно деплоить на app web без ограничений. обобщая, рисовать в apps'ах нужно ничуть не больше и не меньше, чем в самом SP...
>>Андрей, к сожалению, CSOM, JSOM, Rest API сильно проигрывают Server OM по наличию фич
УдалитьНу, например?
Категорически разделяю восхищение автора блока современным технологиям в web! У самого недавно появилось время изучить MVC, написав на нём небольшой проект. И я прямо влюбился в его чистоту разметки, простоту, скорость работы, ( единственно с роутингом не очень понятно сначала всё было) . Всё можно сделать на чистом HTML + библиотек полно. И в месте сJSON это работает невероятно быстро. Нет ужасных вьюстейтов, гененерируемый код минимален и читаемый ) И после этого стал ненавидеть шарепоинтовсике списки, CAML и понимаю, что для создания стандартного приложении шарика тратится уйма времени. а потом ещё чтото не так работает или медленно.. сидишь ковыряешься в логах и в гугле) Разработка под MVС с кучей библиотек через nuget и не только - просто песня! )
ОтветитьУдалить