#c_sharp #aspnet #aspnet_mvc #sharepoint
Closed. This question is opinion-based. It is not currently
accepting answers.
Want to improve this question? Update the question so
it can be answered with facts and citations by editing this post.
Closed 1 год назад.
На работе необходимо будет реализовать систему аналитической отчетности. Содержащую
различные отчеты с множеством данных, полей колонок и фильтром, детальных отчетов и
т.д. Сейчас она реализована в собственной системе отчетности, но руководители хотят
видеть более современный дизайн и поддержку в браузерах. Так же в данный момент система
работает в локальной сети организации, но будет необходимо реализовать доступ к отчетам
через сеть Интернет.
Изначально в планах было реализовать систему на 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);
Возможность простого развертывания и настройки сервера для доступа из сети Интернет;
Настройка безопасности: авторизации, роли, шифрование и т.п.;
На что еще нужно обратить внимание?
Ответы
Ответ 1
Если есть возможность - не используйте 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 и лишено подобных недостатков. Но тут мы возвращаемся к проблеме "зачем вообще приложению шарик".Ответ 2
Если у Вас уже куплен SharePoint – то это может позволить реализовать типовое решение довольно быстро. Если бы Вы уточнили, что имеется в виду под «необходимо будет реализовать систему аналитической отчетности», то можно было бы посоветовать что-то более конкретное. SharePoint довольно гибок, хотя Вам нужно также уточнить, какая именно версия имеется: 2010 или 2013, т.к. между ними большая «пропасть» - а заключается она именно в концепции разработки под данную платформу. В версии 2013 подходы к написанию приложений кардинально поменялись. Я склоняюсь к SP, т.к. в нем уже реализована часть базового функционала, а именно: система ролей, библиотек и списков (включая версионность, синхронизацию, административный интерфейс и т.п.). Многое можно реализовать вообще без программирования (за 10 лет администрирования SharePoint программировать приходилось лишь раз 5). Часть задач можно реализовать через SharePoint Designer. Но опять же, уточните ТЗ, тогда можно будет сказать подробнее, какие именно инструменты SP можно использовать, а что нужно допрограммировать. По пунктам: Натянуть свой шаблон на SP – не самая тривиальная задача, т.к. часть компонентов уже имеют свой дизайн Разработка может вообще не понадобится, но если и понадобится, то со знанием .Net проблем не должно быть Простота установки SP зависит от количества развертываемых ферм Система ролей реализована достаточно хорошо Зависит от ТЗОтвет 3
SharePoint можно воспринимать как CMS c прикрученными Enterprise службами, которые прекрасно в него интегрированы. При этом SharePoint является отличной платформой для разработки в "кровавом ентерпрайзе". Многое, что Вам нужно делать самостоятельно на ASP.NET MVC, в SharePoint делается в "пару кликов". Есть списки, формы к ним, настраиваемые представления, поиск, настройка прав, создание страниц, Web parts, Timer job'ы, Event receiver'ы и еще много очень полезных вещей. Так же стоит отметить возможность быстрой масштабируемости, можно выносить звенья фермы на другие сервера. Используя SharePoint, можно поставлять значимые для бизнеса решения, делать это быстро и с приемлемым качеством. Что касается работы с отчётностью - изучите службы Performance point. Нам удалось с помощью этой службы создать наглядные панели мониторинга. Чем SharePoint плох: SharePoint сложен. Правда. И это требует большого объёма знаний для работы с ним. Обилие возможностей и порождает его сложность. Так же, механизмы SharePoint часто дают очень быстрый старт в начале, а позже можно "упереться" в ограничения "by design". Он использует ASP.NET WebForms, а не ASP.NET MVC. При расширении функционала кодом - надо вписываться в архитектуру SharePoint. Развертывание созданных Вами артефактов (Provision) - еще больше удручает, надо писать кучу XML. Но сейчас уже есть SPMeta (Библиотека и расширение для VS), которая сильно упрощает процесс. Как говорят, самый короткий путь — тот, который знаешь. Используйте ASP.NET MVC и купите контролы для работы с отчётностью. Но Performance point все же посмотрите, может подойдёт. Что касается ответов по пунктам - я полностью согласен с @Ella Svetlaya
Комментариев нет:
Отправить комментарий