2014-01-27 5 views
5

Часто я нахожу это проблематичным при выборе места для размещения папок для ресурсов в папке app\.Структуры папок Laravel

Где я должен поместить такие вещи, как model observers и validators и form macros и repositories .... В настоящее время я делаю следующее

\app 
    \models 
    \controllers 
    \repositories 
    \observers 
    \interfaces 
    \validators 
    \views 

хотя я вижу, что некоторые люди делают следующее:

\app 
    \models 
    \controllers 
    \views 
    \YourAppNameHere 
     \Services 
     \validators 
     \... 

Я не понимаю причину, лежащую в папке \ Acme, когда она совпадает с фактическим приложением?

+0

Оба они хороши, выбирайте тот, который вам подходит лучше всего. На самом деле, не беспокойтесь об этом, придерживайтесь одного, и вам хорошо идти. – Andreyco

+3

Кто-то смотрит Laracasts :) – mikedugan

ответ

8

Лучший способ для управления структурой папки Laravel является обработка app как передний конец каркаса. Если вы посмотрите на git repository, вы увидите, что они отделены друг от друга - вы можете клонировать основную библиотеку, и вы можете клонировать приложение laravel в одиночку. Приложение, с его подпапками, представляет собой один из способов, в рамках которого можно использовать структуру. Конечно, он разработан с учетом лучших практик. Проверьте также основные рамки тесты каталог - там разработчики Laravel обрабатывали библиотеку как «безголовую» - без приложения. Для меня это все, что мне нужно, чтобы схватить Ларавеля.

Таким образом, вы можете изменять существующую структуру, но имейте в виду, что некоторые изменения требуют от вас composer dump-autoload - в основном из-за пространств имен.

+0

Спасибо, это действительно хорошее место для начала поиска. Я полагаю, что моя основная проблема заключается в том, что я часто вижу, что люди в Интернете структурируют свои папки под /lib/validators .../lib/macro ... и, как я вижу, все, что является «доменом приложения», должно находятся под '/ app' и создаются соответствующие пространства имен. Я просто ищу самую лучшую, ясную и самую «красноречивую» структуру. – AndrewMcLagan

1

Короче говоря, это полностью зависит от предпочтений и того, как вы и ваша команда видят, что это лучше для читаемости. Говорят, что хорошо иметь согласованность во всех ваших проектах.

+2

Основная проблема с тем, чтобы быть настолько открытой для любой структуры ....что на самом деле не помогает – AndrewMcLagan

7

По большому счету, Laravel может быть структурирован любым способом, который наилучшим образом подходит для вас. Некоторые люди предпочитают архитектуру по умолчанию, а другую подобную доменную архитектуру.

Оба моих текущих проектов отклоняются от этого, используя что-то вроде:

/app 
    /database 
    /controllers 
    /bin 
    /views 
    /config 
    /storage 

я храню много моих пользовательских функций в поставщика услуг, хотя у меня есть некоторые общие помощники в bin/ вместе с моими маршрутами и фильтры.

Вы можете делать все, что хотите, просто убедитесь, что соответственно обновили свои composer.json и app/start/global.php, чтобы убедиться, что соответствующие классы загружены автоматически. И убедитесь, что вы правильно проложили пространство!

Ниже приведен пример соответствующих разделах моей composer.json и global.php только для идеи:

composer.json:

"autoload": { 
    "classmap": [ 
     "app/commands", 
     "app/controllers", 
     "app/database/models", 
     "app/database/migrations", 
     "app/database/seeds" 
    ] 
}, 

app/start/global.php:

ClassLoader::addDirectories(array(

app_path().'/commands', 
app_path().'/controllers', 
app_path().'/bin', 
    app_path().'/database/models', 
    app_path().'/database/seeds', 

)); 
require app_path().'/bin/filters.php'; 
require app_path().'/bin/helpers.php'; 
require app_path().'/bin/events.php'; 
Смежные вопросы