Одним из первых шагов при разработке веб-приложения является выяснение, как администрировать зверя и где должны жить эти инструменты администратора. Часто это сводится к одному ключевому вопросу: должен ли сам публичный веб-сайт быть административным инструментом? Хотя не существует единого подхода, который работал бы в любой ситуации, я в целом считаю, что разделение административных инструментов более целесообразно, чем встраивание инструментов в общедоступный веб-сайт. Ключевые причины для решения этой проблемы:
Отличающаяся природа зверей
Общедоступные веб-сайты и инструменты администрирования веб-сайтов по своей природе являются принципиально различными видами приложений. Ваш общедоступный веб-сайт должен быть высокодоступным для любого количества браузеров, платформ и пользователей; он должен соответствовать стандартам и Google. С точки зрения развития масштабируемость является серьезной проблемой. Это означает такие вещи, как полное отключение ViewState и, возможно, состояние сеанса или отказ от таких полезных инструментов, как ASP.NET AJAX UpdatePanels, в предпочтении гораздо более упорядоченным сценариям.
С другой стороны, ваши административные инструменты, вероятно, нацелены на очень небольшой набор пользователей на управляемых платформах. Использование полосы пропускания, вероятно, не является серьезной проблемой, а также такие тонкости, как соответствие стандартам, доступность и поисковая оптимизация. Вы можете почувствовать себя свободнее, если ASP.NET станет ASP.NET, и вам не придется беспокоиться о больших размерах ViewState, использовать UpdatePanels, иметь большие переменные Session и притворяться, что вы разработчик рабочего стола. Это весело и бодрящий, не говоря уже о том, чтобы помочь в ускорении процесса разработки.
Гораздо эффективнее просто обрабатывать каждое приложение отдельно и не беспокоиться ни об ограничении набора инструментов, чтобы инструменты администрирования были приятными и общедоступными, ни о компрометации целей сайта, чтобы держать разработку инструмента администрирования в здравом уме.
Управление проектом
Один из фактов жизни заключается в том, что такие важные для руководителей типы вопросов, как «как будет выглядеть этот веб-сайт», как правило, отстают от всех возможных убеждений. Принимая во внимание, что мирские проблемы, такие как «как будет работать этот веб-сайт», как правило, решаются гораздо раньше. Теперь, если и ваши логические инструменты, и рабочий процесс зависят от этих вопросов исполнительного уровня, вы можете оказаться в затруднительном положении, поскольку вы не сможете реально начать значительную конструкцию, пока большие парики не обратят внимание на проект, который они запрашивают. Но, если вы разделили вещи, у вас может быть работающий инструмент администратора, прежде чем кто-нибудь примет те трудные решения, какие именно оттенки розового использовать.
Еще одним преимуществом является то, что, если у вас есть ресурсы, становится намного проще разделить работу между разными членами вашей команды, поскольку им не нужно размышлять об одних и тех же фрагментах кода. Наконец, через 3 года вы можете сделать общедоступный веб-сайт, не прибегая к помощи гораздо более ресурсоемких инструментов разработки.
Безопасность
Использование совершенно отдельного приложения для администрирования открывает множество вариантов безопасности. Во-первых, с точки зрения IIS гораздо проще заставить административное приложение работать по протоколу SSL на уровне веб-сервера. Во-вторых, для тех из нас, кто работает в команде из фольгированной фольги, вы можете еще больше повысить безопасность транспортного уровня, ограничив доступ к инструментам администратора. Это может варьироваться от размещения их за VPN до сохранения их в корпоративном брандмауэре в зависимости от сценария развертывания.
Одной из основных проблем безопасности является повышение привилегий. Теперь, если вы используете «более специальных», но общедоступных пользователей на своем общедоступном веб-сайте для обновления контента, вы — одна из опечаток web.config, открывающая важные разделы ваших инструментов администратора для широкой публики. Тогда как если вы работаете с отдельными приложениями, то такие сценарии не представляют опасности. Вы даже можете использовать совершенно разные методы аутентификации с помощью инструментов администратора, что удобно для корпоративных приложений, где люди используют Active Directory для аутентификации.
Последнее преимущество безопасности на уровне базы данных. Отдельные приложения значительно упрощают и упрощают использование отдельных учетных записей базы данных, позволяя функционально отделять публичные разрешения от личных разрешений вплоть до самого ядра. Это означает, что даже если что-то ужасно выйдет из строя и эксплойт Sql-инъекции превратится в дикую природу, вы все равно можете немного легче дышать, зная, что пользователь базы данных вашего публичного сайта очень, очень заблокирован.
Я бы не советовал использовать этот подход, если только кто-то не принял твердую трехуровневую конструкцию, в которой основная бизнес-логика встроена в третью сборку. Создание сайтов таким способом с использованием SqlDataSource — упражнение в безумии. Но, учитывая правильно структурированный проект, это был довольно успешный метод для меня.
