На работе необходимо будет реализовать систему аналитической отчетности. Содержащую различные отчеты с множеством данных, полей колонок и фильтром, детальных отчетов и т.д. Сейчас она реализована в собственной системе отчетности, но руководители хотят видеть более современный дизайн и поддержку в браузерах. Так же в данный момент система работает в локальной сети организации, но будет необходимо реализовать доступ к отчетам через сеть Интернет.
Изначально в планах было реализовать систему на ASP.NET MVC 5. Но руководство вспомнило что в предприятии куплен SharePoint (2010 или 2013). Он интегрирован с Lync и Outlook, что удобно. Встал вопрос что использовать.
Разрабатывать систему придется начинать мне. Дали время решить что лучше использовать. Но опыт есть только в ASP.NET MVC. После прочтения некоторых статей, стал сомневаться в своем изначальном выборе MVC. SharePoint так же показался привлекательным со своими плюсами.
Систему что на ASP.NET MVC, что на SharePoint придется реализовывать с нуля. Выбор технологии для разработки системы предстоит сделать из стека Microsoft.
Очень важно услышать мнение более опытных и авторитетных людей на счет.
Если можно, то выскажитесь в соответствии с вашим опытом или знаниями, как ASP.NET MVC и SharePoint подходят под эти критерии:
Создание удобного пользовательского интерфейса (скорее простота создания, т.к. скорее всего будет использован Bootstrap;
Простота и скорость разработки (если учесть что разработка будет с нуля и мои познания ограничиваются ASP.NET MVC);
Возможность простого развертывания и настройки сервера для доступа из сети Интернет;
Настройка безопасности: авторизации, роли, шифрование и т.п.;
На что еще нужно обратить внимание?
Ответ
Если есть возможность - не используйте sharepoint! Мы сейчас делаем на нем сложный проект - и стабильно каждую неделю случается, что что-то в шарике просто не работает из-за неучтенных изменений, накопившихся в нем ранее. (Пример - сейчас не могу создать lookup field ни в одном списке через веб-интерфейс из-за того, что не загружается список списков - а не загружается он потому что какой-то из списков где-то на сайте "битый").
Если делать для шарика решение - это тихий ужас. Вместо современного ASP.NET MVC - устаревший ASP.NET WebForms. Шарик должен стоять на каждом компе разработчика - иначе студия не сможет даже открыть проект. Шарик должен стоять даже на билд-агенте! Иногда общую для нескольких проектов сборку приходится деплоить в GAC. После этого эту сборку надо обновлять в GACе каждый раз перед использованием - то есть нельзя даже консольную утилиту отладить или тесты прогнать без деплоя решения на сервер.
С автоматическим деплоем - тоже веселье. После установки решения на ферму надо отдельно активировать его возможности (они же фичи). Причем активировать их нельзя пока решение не установится полностью - а команды дождаться нету. Более того, нет простого и очевидного способа определить, устанавливается сейчас решение или не смогло установиться - в обоих случаях будет статус NotDeployed. Кстати, можно запросто удалить решение без деактивации его фич. После этого фичи уже невозможно деактивировать (да, вот так у меня на рабочем компе и появился битый список из первого абзаца).
Если же делать для шарика не решение, а приложение - то всей этой радости, разумеется, не возникает. Но и возможностей тут куда меньше. И тут возникает другой вопрос... Каждое приложение - отдельный сайт. Зачем приложению вообще нужен шарик, что от него можно получить?
Авторизация пользователей? Но шарик использует внешнюю STS для этих целей, без нее просто не будет работать связь с приложениями. Но тогда и текущего пользователя можно узнавать не у шарика, а у STS.
Хранилище данных? Но у шарика очень тормозные списки. Что неудивительно, если покопаться в их внутреннем устройстве.
Управление конфигурацией? Но если делать автоматическое развертывание - то шарик не упрощает процесс, а лишь ставит палки в колеса.
В итоге получается, что шарик как платформа не может предоставить ничего интересного, что можно было бы использовать.
В каком же случае шарик имеет смысл использовать? Использовать его имеет смысл, если он в архитектуре является не платформой, а приложением. Если в числе стандартных или сторонних, но уже готовых решений есть именно то, что вам надо. В таком случае имеет смысл использовать это самое готовое решение, и дорабатывать его или с ним интергироваться. Но не следует помещать его в центр своей архитектуры.
UPD. По пунктам из вопроса.
Пользовательский интерфейс на WebPages делать удобнее нежели на WebForms. А решения шарика используют WebForms.
Разрабатывать решения под шарик очень сложно. В документации на msdn нет даже такой важной информации, какие объекты надо закрывать, а какие не надо. Точнее, информация есть - но в отдельной статье, а не в доках по классам. И все такие статьи придется найти и выучить.
Установка решения на шарик вручную, через веб-интерфейс - довольно простая. Но ее автоматизация - это ад. Кроме того, само по себе развертывание шарика - тоже тот еще ад.
У шарика есть красивый веб-интерфейс для редактирования прав. Но только для встроенных в шарик же объектов.
У ASP.NET MVC куда больше возможностей по управлению безопасностью именно с точки зрения программиста.
Разумеется, все вышеперечисленное относится к решениям шарика, а не приложениям. Приложение пишется на том же ASP.NET MVC и лишено подобных недостатков. Но тут мы возвращаемся к проблеме "зачем вообще приложению шарик".
Комментариев нет:
Отправить комментарий