초보

7596 단어 laravel5
디 렉 터 리 구조 변화
laravel 5 가 가장 먼저 강조 하 는 것 은 프로젝트 디 렉 터 리 구조의 변화 이 고 4.2 와 차이 가 매우 크다 는 것 이다.조목조목 말 해 보 자.
새로운 디 렉 터 리 구 조 는 이렇게 보 입 니 다.
app
    Commands
    Console
    Events
    Handlers
        Commands
        Events
    Http
        Controllers
        Middleware
        Requests
        Kernel.php
        routes.php
    Providers
    Services
bootstrap
config
database
    migrations
    seeds
public
    package
resources
    lang
    views
storage
    cache
    logs
    meta
    sessions
    views
    work
tests
4.2 디 렉 터 리 구조:
app
    commands
    config
    controllers
    database
    lang
    models
    start
    storage
    tests
    views
bootstrap
public
비교 해 보면 변경 사항 이 비교적 큽 니 다.config,database 가 루트 디 렉 터 리 로 이동 되 었 습 니 다.lang,views 디 렉 터 리 가 resources 디 렉 터 리 로 이동 되 었 고 controllers 는 http 디 렉 터 리 에 통합 되 었 습 니 다.models 디 렉 터 리 가 보이 지 않 았 으 며 새로 추 가 된 디 렉 터 리 도 있 습 니 다.
앱 네 임 스페이스
laravel 5 에 또 하나의 변화 가 있 습 니 다.바로 app 디 렉 터 리 에 기본 이름 공간 App 을 추가 한 것 입 니 다.App 에 있 는 모든 디 렉 터 리,클래스 는 이 이름 공간 에서 이 루어 져 야 합 니 다.쉽게 말 하면 psr 4 기준 을 사용 한 것 입 니 다.
HTTP
laravel 5 는 새로운 디 렉 터 리 구 조 는 현재 가장 좋 은 구조 중 하나 로 우리 의 개발 을 더욱 원활 하 게 할 수 있다 고 생각 합 니 다.예 를 들 어 http 디 렉 터 리:
Http
    Controllers
    Middleware
    Requests
    Kernel.php
    routes.php
Middleware 는 매우 낯 설 습 니 다.사실은 원래 의 경로 filter 의 업그레이드 버 전 입 니 다.지금 은 filter.phop 에서 필 터 를 정의 하지 않 아 도 됩 니 다.대신 Middleware 디 렉 터 리 에 클래스 를 만 들 고 Kernel.phop 에서 전역 을 설정 할 지 선택 할 수 있 습 니 다.전역 적 인 Middleware 는 모든 요청 이 실 행 됩 니 다.선택 할 수 있 는 것 은 원래 의 filter 에 해당 합 니 다.경로 에서 사용 할 수 있 습 니 다.컨트롤 러 에서 도 사용 할 수 있다.
Requests 는 핵심 클래스 Request 에 대한 확장 입 니 다.서로 다른 Requests 클래스 를 확장 하고 다른 기능 을 추가 할 수 있 습 니 다.
http 요청 과 관련 된 모든 처 리 는 http 디 렉 터 리 에 있 습 니 다.예 를 들 어 컨트롤 러 는 요청 을 받 아들 이 고 되 돌아 오 는 것 이기 때문에 Http 디 렉 터 리 에 두 는 것 이 합 리 적 이 라 고 볼 수 있 습 니 다.
경로
경로 가 이전 과 크게 다 르 지 않 지만 주의해 야 할 것 은 우리 가 컨트롤 러 네 임 스페이스 를 지정 할 때 네 임 스페이스 는 절대적 인 경로 가 아니 라 App\Http\Controllers 에 비해 예 를 들 어:

Route::controllers([
    'auth' => 'Auth\AuthController',
    'password' => 'Auth\PasswordController',
]);
App/Http/controllers/auth 디 렉 터 리 에서 해당 하 는 종 류 를 찾 을 수 있 습 니 다.
또한,루트 는 캐 시 를 지원 하여 성능 을 향상 시 키 고 명령 행 도 구 를 통 해

php artisan route:cache
쉽게 생 성 되 고 통과 할 수 있 습 니 다.

php artisan route:clear
캐 시 정리.
Services
우 리 는 App 디 렉 터 리 아래 에 또 하나의 Services 디 렉 터 리 가 있 는 것 을 보 았 다.나 는 이것 이 매우 좋 은 이념 이 라 고 생각한다.지금까지 나 는 컨트롤 러 에 큰 업무 논리 코드 가 나타 나 는 것 에 대해 짜증 이 났 다.나 는 하나의 단독 층 으로 이런 업무 논 리 를 포장 하고 싶다.서 비 스 는 이 일 을 할 수 있다.물론 필요 한 것 이 아니 지만 나 는 강력 히 사용 하 는 것 을 건의 했다.laravel 5 가 가 져 온 demo 로 보 세 요.

# Http/Controllers/Auth/AuthController.php
<?php namespace App\Http\Controllers\Auth;
use App\Http\Controllers\Controller;
use Illuminate\Contracts\Auth\Guard;
use Illuminate\Contracts\Auth\Registrar;
use Illuminate\Foundation\Auth\AuthenticatesAndRegistersUsers;
class AuthController extends Controller {
    /*
    |--------------------------------------------------------------------------
    | Registration & Login Controller
    |--------------------------------------------------------------------------
    |
    | This controller handles the registration of new users, as well as the
    | authentication of existing users. By default, this controller uses
    | a simple trait to add these behaviors. Why don't you explore it?
    |
    */
    use AuthenticatesAndRegistersUsers;
    /**
     * Create a new authentication controller instance.
     *
     * @param  \Illuminate\Contracts\Auth\Guard  $auth
     * @param  \Illuminate\Contracts\Auth\Registrar  $registrar
     * @return void
     */
    public function __construct(Guard $auth, Registrar $registrar)
    {
        $this->auth = $auth;
        $this->registrar = $registrar;
        $this->middleware('guest', ['except' => 'getLogout']);
    }
}
이것 은 로그 인 권한 을 수 여 받 은 컨트롤 러 입 니 다.우리 가 보기 에는construct 구조 함수,매개 변 수 를 이용 하여 자동 으로'인터페이스 구현(매 뉴 얼 IoC 참조)'의 바 인 딩 을 주입 하 였 습 니 다.Registrar 를 보 겠 습 니 다.

<?php namespace App\Services;
use App\User;
use Validator;
use Illuminate\Contracts\Auth\Registrar as RegistrarContract;
class Registrar implements RegistrarContract {
    /**
     * Get a validator for an incoming registration request.
     *
     * @param  array  $data
     * @return \Illuminate\Contracts\Validation\Validator
     */
    public function validator(array $data)
    {
        return Validator::make($data, [
            'name' => 'required|max:255',
            'email' => 'required|email|max:255|unique:users',
            'password' => 'required|confirmed|min:6',
        ]);
    }
    /**
     * Create a new user instance after a valid registration.
     *
     * @param  array  $data
     * @return User
     */
    public function create(array $data)
    {
        return User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => bcrypt($data['password']),
        ]);
    }
}
사용자 이름 비밀 번 호 를 제출 할 때의 처리:

public function postRegister(Request $request)
{
    $validator = $this->registrar->validator($request->all());
    if ($validator->fails())
    {
        $this->throwValidationException(
            $request, $validator
        );
    }
    $this->auth->login($this->registrar->create($request->all()));
    return redirect($this->redirectPath());
}
폼 검증 의 업무 논 리 는 한 줄 에 불과 합 니 다.

$validator = $this->registrar->validator($request->all());
전체 컨트롤 러 의 코드 는 깨끗 하고 읽 기 쉬 워 보 입 니 다.우 리 는 많은 통용 되 는 업무 논 리 를 service 로 포장 할 수 있 습 니 다.이도 저도 아 닌 컨트롤 러 류 에 직접 포장 하 는 것 보다 좋 습 니 다.
모형.
models 디 렉 터 리 가 보이 지 않 습 니 다.모든 응용 프로그램 이 데이터 베 이 스 를 사용 해 야 하 는 것 이 아니 기 때문에 laravel 5 는 기본적으로 이 디 렉 터 리 를 제공 하지 않 습 니 다.또한 App 이라는 namespace 를 제공 하기 때문에 저 희 는 스스로 App/에서 Models 디 렉 터 리 를 만 들 수 있 습 니 다.그 중에서 모든 모델 류 는 namespace App\Models 라 고 부 릅 니 다.즉,사용 에 있어 서 예전 보다 좀 번 거 롭 고 먼저 use 가 필요 하지만 이렇게 하면 프로젝트 구조 가 더욱 뚜렷 해 지고 모든 라 이브 러 리 는 네 임 스페이스 의 조직 아래 있다.
시간 이 제한 되 어 있 으 니 우선 이렇게 많이 쓰 세 요.예 쁘 게 봐 주 셨 으 면 좋 겠 습 니 다.

좋은 웹페이지 즐겨찾기