초보
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 가 필요 하지만 이렇게 하면 프로젝트 구조 가 더욱 뚜렷 해 지고 모든 라 이브 러 리 는 네 임 스페이스 의 조직 아래 있다.
시간 이 제한 되 어 있 으 니 우선 이렇게 많이 쓰 세 요.예 쁘 게 봐 주 셨 으 면 좋 겠 습 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Laravel5 튜토리얼 블로그 돌아가기 (2) 블로그 기사 투고 양식 만들기전회까지로, DB·테이블의 설정을 할 수 있었으므로, 이번은 관리 화면측의 블로그 기사를 투고하는 폼을 만들어 갑니다. 우선, 보존 처리 등은 생각하지 않고, 간단하게 View 템플릿을 읽어 표시하는 것만의 처리를 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.