Лучшие 3 причины не разработать “систему блога”, которая генерирует aspx файлы на лету
В этом вопросе OP подразумевает, что он хочет основывать систему блога, которую он разрабатывает на автоматическом создании .aspx файлов, один для каждой новой записи в блоге. В моем ответе на его вопрос (который связан с чем-то еще), я сказал ему, что отговорю его использовать такой подход, но не приводя настоящих причин. Он теперь желает причины, почему это не хорошая идея, и я использую этот вопрос видеть, может ли сообщество придумать принуждение достаточного количества списка причин для него использовать другой подход, такой как одно использование DBMS, повторного использования кода, перезаписи URL, MVC, и что нет.
3 ответа
Существует два основных типа платформ публикации CMS:
- Те, которые генерируют контент статически . Некоторые издательские платформы генерируют контент статически. В этом случае сгенерированные файлы не являются динамическими и должны быть файлами HTML. Система должна иметь возможность регенерировать все, например, если шаблон изменился. Было время, когда это решение имело некоторые преимущества:
- безопасность : безопасность управляется на уровне файловой системы
- поиск : полнотекстовый поиск был простым, потому что все было основано на файлах
- , производительность : потребляет меньше ресурсов ЦП.
- интерактивность : невозможно
- распространение контента : единственная причина для создания или выбора такой платформы заключается в том, что контент необходимо распространять через другой канал, кроме Интернета , например CD, загружаемый журнал и т. Д.
.
- Те, кто отображает контент динамически . Для веб-сайта самый простой способ - это отображать страницу динамически.
- безопасность : безопасность можно проверить с помощью сложной схемы и т. Д.
- search : поисковая система развивается и теперь прекрасно интегрируется с гетерогенными источниками: может быть полный текст в базе данных, файлах и т. д.
- производительность : это больше не проблема.
- интерактивность : это намного более гибко: контент может быть адаптирован для посещающего пользователя, люди могут оценивать страницу, добавлять комментарии и т. Д.
- распространение контента : должно быть онлайн, из конечно
Гибридная система, в которой вы генерируете статический файл, который будет визуализироваться динамически (.aspx), для меня бессмысленна - у нее есть недостатки обоих.
.aspx-страницы предназначены для динамической генерации HTML (и javascript и т. Д.) .). Либо один и тот же небольшой набор страниц .aspx должен генерировать вывод для всех записей блога (хранящихся в серии полей), либо (по соображениям производительности) предварительно сгенерированный html может храниться на страницах db (лучше всего) или .html.
При создании страницы .aspx для каждой записи в блоге создается инструмент для создания контента. Для нормального в этом нет смысла. В этой системе будут ненужные накладные расходы. Не зная его точного плана , я все же могу быть уверен, что по крайней мере некоторые из следующего применимы:
- дублирование кода на страницах .aspx, большие трудности с обновлением макета / поведение сайта
- существенные и ненужные накладные расходы из-за того, что IIS приходится обрабатывать и постоянно перекомпилировать множество дополнительных страниц .aspx.
- поиск будет кошмаром, так как контент будет в файлах . Сложно настроить, и он никогда не будет эффективным.
- редактирование, добавление комментариев, модерирование будет. . . очень трудно.
- безопасность будет усложнена
Генерирование отдельных ASPX файлов для каждой статьи является неэффективным использованием ресурсов сервера:
каждый новый aspx файл будет компилироваться в DLL. Это означает дополнительные затраты времени на компиляцию статьи + затраты памяти на воссоздание нового AppDomain, который содержит эту новую DLL
можно настроить ASP.Net на компиляцию всех ASPX файлов в один DLL файл, но это будет еще хуже: ВСЕ статьи придется перекомпилировать каждый раз, когда создается новая статья
Более приемлемым решением (но даже в этом случае я не рекомендую его) было бы создание статических .html файлов.