субдомен по сравнению с подкаталогом в веб-программировании
Альтернатива ответам darindaCoder :
path = r'C:\DRO\DCL_rawdata_files' # use your path
all_files = glob.glob(os.path.join(path, "*.csv")) # advisable to use os.path.join as this makes concatenation OS independent
df_from_each_file = (pd.read_csv(f) for f in all_files)
concatenated_df = pd.concat(df_from_each_file, ignore_index=True)
# doesn't create a list, nor does it append to one
9 ответов
Помимо того, что с точки зрения безопасности немного проще изолировать приложение внутри субдомена, я просто прокомментирую то, что, на мой взгляд, является самой большой разницей между ними.
Pro для субдоменов:
- Вы можете изолировать конфигурацию (например, apache) для каждого домена.
- Будет проще переносить части вашего приложения на другие машины. Подкаталоги на самом деле не дадут вам такой гибкости.
- Вместо того, чтобы использовать переменную $baseUri в каждом html шаблоне, вы можете просто предположить, что корень приложения всегда /.
Cons:
- Это будет намного более раздражающе для быстрой установки инсценировки или временных сред разработки. Теперь для каждого 'приложения' вам понадобится DNS записей хост-файлов и конфигурация веб-сервера. С подкаталогами вы можете бросить приложение в каталог и идти!
- Если у вас когда-нибудь будет требование развернуть ваше приложение на другой системе, где использование / невозможно из-за какой-то странной политики, возможно, потребуется переписывание.
Мой совет:
Убедитесь, что вы всегда можете сделать и то, и другое, что даст вам лучшее из обоих миров. Каждая часть вашего приложения должна иметь настраиваемую базу uri, которая всегда соблюдается. До тех пор, пока вы убедитесь, что вы всегда можете идти в обе стороны, то кому какое дело, что вы делаете? это просто урл и его всегда можно изменить.
Там уже были отличные ответы, так что вы можете проверить эти ссылки в любое время.
- С точки зрения организации кода: Различия равны нулю, так как можно сопоставить поддомены с любым каталогом.
- С точки зрения безопасности браузера: Доступ к JavaScript через субдомены возможен, но имеет препятствия (см.
document.domainи consorts). Я не знаю ничего на стороне JavaScript, что совершенно невозможно при работе с различными субдоменами.
Мнение:
Я лично склоняюсь к каталогам и против субдоменов для публичных адресов. Широкая общественность привыкла к веб-адресам, начинающимся с "www.", и это создает ненужную путаницу, чтобы разорвать эту закономерность. Вы заметите, что очень часто люди, получив субдомен для ввода в адресную строку, автоматически начинают набирать "www." и с удивлением узнают, что адрес может быть и без.
Для меня, единственный хороший способ использования субдоменов - это для внутренних целей, чтобы облегчить или подготовить к использованию различных серверов (например, static.example.com, images.example.com и т.д.)
.Лично я предпочитаю использовать поддомен для каждого приложения, а затем поддомены (независимо от того, являются ли они поддиректориями на самом деле или нет -- желательно, чтобы они просто перенаправлялись в /index.php от .htaccess) для обозначения различных состояний этого приложения. For example:
admin.blah.com/users/1234/bob,
admin.blah.com/pages/4321/title,
blog.blah.com/archives/2007/5678/title,
и т.д.
Поддомен сообщает вам , где вы находитесь, а поддиректории говорят вам , что вы делаете.
- Вы можете легко "делать" виртуальные серверы на субдоменах.
- Вы можете разделять субдомены на разные куки.
Лучше всего распознать, что субдомены - это "главное" разделение в веб-пространстве, а поддиректории - это "второстепенные". Субдомены предназначены для разных доменов; на разных субдоменах могут работать разные люди с разными приложениями. Подкаталоги - это разделы одного (суб)домена, разделяющие, возможно, разные приложения одним и тем же пользователем.
Web-стандарты намеренно очень открыты, но чем больше вы будете злоупотреблять ими для создания странных иерархий, тем больше они будут кусать вас в конце концов.
.Одним из основных преимуществ субдоменов является то, что файлы, на которые они указывают, могут находиться где угодно - даже на другом сервере. Наиболее часто я использую субдомен при разработке живого проекта. Например, вы можете создать поддомен:
dev.example.com
и сделать копию вашего живого сайта, включая всю структуру каталогов. Загрузите файл .htaccess, чтобы отказать в соединении кому-либо, кроме вас и IP вашего клиента, и используйте его для внесения изменений до тех пор, пока обновления не будут готовы к запуску в реальном времени.
.Это довольно большая тема, но вот некоторые мысли о субдоменах...
Pros
Могут использовать "чистую" настройку маршрутизации, если вы используете MVC.
Очень четкое разделение между частями система и отсутствие опасности пространства имён пересекаются.
Происходит
- С другой стороны, есть вероятно , чтобы больше дублировать код на в задней части, если только ты не умна в том. библиотека/включает в себя каталоги и использование общая зона.
С точки зрения SEO, нет большая разница в наши дни и, конечно же, такие инструменты, как Google Аналитики могут быть проинструктированы об использовании определенного домена протоколирования
.Что-то связанное, но не полный ответ: поддомены могут увеличить производительность при использовании для css/образов/js.
Лично мне нравится подход Карсона .
Я думаю, что тремя наиболее важными причинами использования субдоменов, в отличие от суб / каталогов, являются безопасность, безопасность и безопасность. Подкаталоги открывают сеанс сервера для хакеров.
Например, если у меня есть два веб-приложения, которые я помещаю в каталоги, они обычно будут использовать один и тот же сеанс (если не будут предприняты определенные шаги для его предотвращения / поддержки). Итак, если у меня есть:
domain.com/application1
домен.com / application2
Если application2 будет взломано, хакер сможет увидеть все переменные сеанса, которые были установлены в application1. На этом этапе безопасность вашего сеанса снижена до уровня самого слабого субприложения, то есть самого слабого звена в цепочке.