728x90
반응형

설정보다 관례(CoC; Convention over Configuration)는 소프트웨어 개발자가 정해야 하는 수많은 결정들을 줄여주고 단순성을 확보하면서도 유연함을 잃지 않기 위한 설계 패러다임입니다.

 

프레임워크가 복잡해 지고 기능이 방대해짐에 따라 사용하기 위해서는 수많은 설정 파일과 세팅을 해야 하는 부담이 생겨났고 CoC는 이를 해결하기 위해 자주 사용하는 부분은 관례를 정하여 생략하고 이를 따르지 않을 경우에만 설정을 하도록 하고 있습니다.

 

많은 현대적인 프레임워크(Spring Framework, Ruby on Rails, Symphony 등)이 CoC 패러다임을 사용하고 있으며 라라벨도 CoC 패러다임에 입각하여 설계되었고 제공되는 기능들은 관례를 따르고 있습니다.

 

혹자는 CoC 패러다임을 적용하면 자유도가 떨어진다는 의견도 있지만 팀으로 일하게 되는 소프트웨어 개발 프로젝트의 특성상 표준화와 규격화가 정해지지 않는다면 공유와 협업이 힘들어 지고 잘못된 설정등으로 인한 버그 발생 소지가 크며 유지 보수가 어려워 지는 문제가 있습니다.

 

예를 들어 블로그 서비스를 개발하고 있고 게시 글의 카테고리를 저장하는 테이블인 article_categories 를 만들었을 경우 라라벨은  관련 모델 클래스는 ArticleCategory 라고 가정하고 동작하므로 개발자는 모델과 일치하는 테이블 이름이 다른 경우에만 설정을 하면 됩니다.

또 로그인을 처리하는 URL이 /auth/login(라라벨 5.1) 또는 /login(라라벨 5.2)이라고 가정하고 있으며 로그인에 성공할 경우 /home URL 로 리다이렉트 하도록 관례가 설정되어 있으므로 설정을 생략하고 별도의 URL 을 사용할 경우에만 설정을 해주면 됩니다.


CoC 는 이렇게 많은 설정 파일을 관리하고 세팅을 해주어야 하는 부담에서 벗어나 애플리케이션 개발에 집중할 수 있게 해주는 훌륭한 패러다임이지만 한 가지 문제가 있습니다.


관례를 모르면 어떻게 동작하는지 이해를 할 수가 없으므로 관례를 따르지 않을 경우(레거시 데이타베이스 등) 나 커스터마이징시 많은 어려움을 겪을 수 있으며 어디에서 관례를 찾아야 하는지 알기 힘들다는 점입니다.


출처 : https://www.lesstif.com/display/LIFE

728x90
반응형
728x90
반응형

의존성 주입(DI; Dependency injection)과 제어 역전(IoC; Inversion of Control)은 모듈간의 의존성을 줄이고 소스 수정없이 런타임에 더욱 유연한 소프트웨어를 만들수 있는 개발 패턴입니다.

 

의존성 주입은 객체 지향 언어에서 제공하는 인터페이스(Interface) 를 활용하여 구현됩니다.

 

사용자의 정보를 저장하고 읽어오는 UserRepository 클래스가 있고 이 안에는 저장소에서 사용자의 정보를 처리하는 $repository 라는 변수가 있습니다.

서비스 초기고 사용자가 적어서 사용자의 정보는 콤마로 구분된 CSV 파일에서 읽기로 하였습니다. 물론 향후 확장성을 위해 RepositoryInterface 라는 인터페이스를  만들고 CSVRepository 는  이를 구현한 클래스입니다.

1
2
3
4
5
6
7
8
9
10
 <?php
  
class UserRepository implements RepositoryInterface {
    private $repository;
  
    public function __construct() {
        $this->repository = new CSVRepository;
    }
}
  

이제 서비스 코드는 다음과 같이 인터페이스를 구현한 클래스의 인스턴스를 생성한 후 사용하도록 작성합니다.

// repository 생성 및 사용
$repos = new UserRepository();
$repos->store();

 

이제 서비스 사용자가  많아져서 사용자 정보를 MySQL DBMS 에서 처리하기로 하고 관련 로직을 구현하였습니다. 그리고 UserRepository 를 다음과 같이 수정합니다.

 <?php
  
class MySQLUserRepository implements RepositoryInterface {
    private $repository;
  
    public function __construct() {
        $this->repository = new MySQLRepository;
    }
}
// repository 생성 및 사용
$repos = new MySQLUserRepository();
$repos->store();

 

서비스는 더욱 사용자가 많아지고 성능 개선을 위해 저장소를 레디스(redis) key/value store 로 변경하기로 했습니다.

인터페이스를 잘 설계하고 이를 구현했다면 위와 같은 상황에서 RedisUserRepository 클래스를 구현하고 기존 서비스의 인스턴스 생성 소스를 수정하여 대처할 수 있습니다.

 <?php
  
class RedisUserRepository implements RepositoryInterface {
    private $repository;
  
    public function __construct() {
        $this->repository = new RedisRepository;
    }
}

 

하지만 외부에서 이 제품을 사용하겠다는 곳이 2개가 나타났는데 각각 DBMS 를 MS-SQL 과 PostgreSQL 을 사용한다고 합니다.

사용자 저장소를 인터페이스로 만들었지만 실제 서비스 코드에서는 인터페이스를 구현한 코드가 들어가야 하며 고객이 사용하는 DB 에 따라 제품을 나눌 경우 버전 관리가 매우 힘들어 지게 되며 새로운 DB가 추가될 경우 인스턴스를 생성하는 코드도 계속 수정되어야 합니다.

 <?php
  
class MSSQLUserRepository implements RepositoryInterface {
    private $repository;
  
    public function __construct() {
        $this->repository = new MSSQLRepository;
    }
}
// repository 생성 및 사용
$repos = new MSSQLUserRepository();
$repos->store();

 

의존성 주입과 제어의 역전 기술을 사용하면 인터페이스를 사용하는 소스의 수정없이 런타임에 의존성을 결정할 수 있습니다.

 <?php
  
class UserRepository implements RepositoryInterface {
    private $repository;
  
    public function __construct(RepositoryInterface $repository) {
        $this->repository = $repository;
    }
}

이제 의존성 제어 처리 로직에서 설정 파일이나 옵션에서 RepositoryInterface 를 구현한 인터페이스를 생성하여 UserRepository 에 주입해 주면 다른 저장소를 사용하는 곳이 나타나도 소스 수정을 하지 않고 설정으로 처리할 수 있습니다. 

$repos = App:make('UserRepository');
// $repos 사용

 

위와 같은 기법을 의존성 주입이라고 하며 외부에서 의존성이 주입되므로 이런 제어를 제어의 역전이라고 부릅니다. 

의존성 주입은 일반적인 서비스나 애플리케이션에서는 고려하지 않아도 되는 경우가 많지만 외부 환경에서 구동해야 하는 제품(솔루션, 프레임워크)은 도입을 고려해 봐야 하는  기능입니다.

 

의존성을 주입하는 방법은 위에서 설명한 생성자를 이용하는 방법과 세터(setter) 를 이용하는 방법이 있는데 라라벨은 전자를 사용하고 있습니다.

 

라라벨은 많은 부분을 런타임에 의존성을 주입하고 있으며 주입할 의존성 인터페이스는 타입 힌트를 통해 결정하고 있습니다.

또 의존성 인터페이스를 구체적으로 구현한 프로바이더는 보통 설정 파일에서 읽어 오므로 설정 파일의 내용만 변경하면 애플리케이션을 수정하지 않고 유연하게 패키지를 사용할 수 있습니다.

예로 config/session.php 내 세션 드라이버 설정을 다음처럼 한 줄만 바꾸면 캐시 데이타 저장소를 파일 시스템에서 DBMS 로 또는 redis 나 memcache 같은 key/value store 로 변경할 수 있습니다.

// 파일 세션 드라이버에서 레디스로 변경
//'driver' => env('SESSION_DRIVER', 'file')
'driver' => env('SESSION_DRIVER''redis')


출처 : https://www.lesstif.com/display/LIFE

728x90
반응형
728x90
반응형

라라벨 프레임워크는 컴포넌트(Component) 기반으로 기능을 확장할 수 있으므로 사용자는 손쉽게 원하는 기능이 없을 경우 이를 사용하여 기능을 확장할 수 있습니다.

또 기존 PHP 코드가 있다면 기존 코드를 크게 흔들지 않고 이를 라라벨 패키지로 재작성할 수 있습니다.

 

라라벨은 프레임워크의 코어와 패키지가 분리되어 있으므로 외부에서 만든 패키지를 탑재할 수 있으며 특히 컴포저(Composer) 를 지원하는 패키지라면 명령어 한 줄로 손쉽게 외부 패키지를 사용할 수 있습니다.

 

실제로 라라벨에서 제공하는 여러 패키지는 심포니(Symphony) 프레임워크에서 제공하는 기능을 확장하거나 또는 그대로 차용한 것도 많이 있습니다.

http://symfony.com/projects/laravel 에서 라라벨이 사용하는 심포니 프레임워크의 컴포넌트를 확인할 수 있습니다.

 

라라벨은 패키지 관리자로 컴포저(Composer)를 사용하므로 손쉽게 패키지간 의존성 관리를 할 수 있으며 http://packagist.org 같은 온라인 PHP 패키지 저장소에서 손쉽게 검색과 설치가 가능합니다.


출처 : https://www.lesstif.com/display/LIFE

728x90
반응형
728x90
반응형

PHP 기반으로 웹 서비스를 제공할 경우 실제 파일 시스템과 웹 서비스의 URL 이 일치하도록 제공하는 경우가 많았습니다.

만약 웹 서비스의 소스 디렉터리(DocumentRoot)가 /var/www/example.com 일 경우 다음과 같은 디렉터리를 만들고 웹 브라우저에서는 http://example.com/cart/view.php 를  호출할 경우 /var/www/example.com/cart/view.php 를 실행한 후 결과를 브라우저에 전송했습니다.

$ tree -f
.
├── ./cart
│   └── ./cart/view.php
└── ./user
├── ./user/login.php
└── ./user/regist.php

 

서비스의 URL은 "http://example.com/kb/index.php?cat=8&id=41" 처럼 URL 에 GET 파라미터를 넘겨서 웹 서비스를 호출하는게 일반적이었습니다.

 

이는 웹 서비스가 파일 시스템과 일치하여 종속적이 되고 URL 을 기억하기 어렵게 해서 사용자의 웹 접근성을 떨어뜨리는 문제가 있습니다. 

 

Pretty URLs 은 Clean URLs, user-friendly URLs 라고도 하며 "http://example.com/kb/8/41" 처럼 사용자가 기억하기 쉽고 파일 시스템과 분리된 URL 로 서비스를 제공하는 것을 의미하며 라라벨을 사용하면 간단하게 Pretty URLs 기반의 웹 서비스를 만들 수 있습니다.


출처 : https://www.lesstif.com/display/LIFE

728x90
반응형
728x90
반응형

PHP 로 웹 개발을 할 경우 뷰 레이어 코드를 작성할 때 HTML 내에  <?php echo $val; ?>  와 같이 데이타를 출력하는 코드를 넣는 것은 매우 귀찮고 실수할 여지가 많은 작업이었습니다.

 

라라벨은 blade 라는 심플하고 사용이 쉬운 템플릿(template) 엔진을 내장하고 있으므로 뷰 코드를 작성할 때 이런 수고를 더 이상하지 않고 MVC 패러다임에 맞는 개발을 할수가 있습니다.

템플릿 엔진

 

블레이드는 상속을 지원하므로 레이아웃이나 jQuery 를 포함하는 <script> 구문같이 페이지마다 공통적으로 계속 사용해야 하는 부분은 상속을 통해 체계적으로 관리할 수 있습니다.

 

블레이드 템플릿을 사용하면 HMTL 과 CSS 를 바로 사용하고 PHP 구문만 특정 태그로 처리하면 되므로 디자이너와 개발자간의 협업도 기존에 비해 용이해 집니다.

 

블레이드의 또 다른 장점중 하나는 뷰 레이어에 출력을 하기 위해 {{ }} 를 호출하면 e() 라는 헬퍼 함수로 변환하고 헬퍼 내부에서 htmlspecialchars() 호출을 통해 위험한 특수 문자열을 자동적으로 변환해 줍니다.

그러므로 뷰에 출력할 때마다 직접 htmlspecialchars() 로 필터링할 필요가 없으지므로 코드의 양이 줄고 혹시 모를 실수로 인해 XSS(Cross Site Script) 공격을 당할 위험을 줄여 줍니다.


출처 : https://www.lesstif.com/display/LIFE

728x90
반응형

+ Recent posts