fremework 과 symfony

출처 : http://gitagy.tistory.com/tag/symfony

Framework을 사용해야 하는 이유

대학원 졸업을 앞두고 며칠간 석사 논문 테마때문에 식음을 전폐하였습니다. 세상을 놀라게할 정도는 아니지만, 나름대로 새로운 것을 써보고 싶은 욕심 때문이었습니다. 그러나 문제는 아는 것이 그다지 없기 때문에 괜찮은 테마를 고를 안목도 없었고, 또한 괜찮은 테마를 고른다고 해서 논문으로 완성되리라는 보장도 없었습니다. 이런 제 모습을 옆에서 지켜 보고 있던 선배는 (평소에 말을 많이 아끼셨던 분이였습니다..) 안타까웠던지 충고를 해 주었습니다.

“Hani야~ 지금 우리가 서 있는 이 기계공학이라는 산은 한 사람이 만든 산이 아니라는 사실을 알지? 너와 나같은 평범한 사람이 산을 오르면서 쌓아 놓은 작은 돌들이 모여서 지금의 산이 된거야. 그러니까 산을 쌓기 보다는 자그마한 돌을 산위에 두고 온다는 심정으로 논문 테마를 찾아 보는게 어떨까?”

평소에 들으면 그냥 그런 이야기로 들릴 수 있지만, 며칠을 답도 없는 문제에 골머리를 싸매고 고생하던 저에게는 큰 깨달음을 주는 충고였습니다. 그덕분에 개인적으로 어느정도 만족하는 선에서 논문을 끝낼 수 있었습니다.

실무에 있어서도 마찬가지입니다. 간혹 개발자들은 자신이 할 수 있는 전부를 보여주고 싶어 합니다. 물론 열정이라는 측면에서 본다면 바람직한 현상입니다. 그러나 실무는 일의 과정보다는 결과에 많은 의미를 부여합니다. 따라서 중간 과정이 아무리 값지다 하더라도 최종적인 결과를 얻지 못한다면 값진 중간 과정의 의미가 퇴색됩니다. 그렇기 때문에 개발자는 효율성의 측면에서 개발 업무를 바라 보는 것이 중요합니다.

“거인의 어깨 위에 있는 난쟁이”라는 표현이 있습니다. 평범한 개발자가 가지고 있는 지식에는 한계가 있습니다. 즉, 지적인 측면에서 말한다면 대가에 비해서 개발자는 난쟁이라 할 수 있습니다. 그러나 거인의 어깨 위에 선 난쟁이를 생각해 보면 더 멀고 더 많은 것을 볼 수 있음을 짐작할 수 있습니다. 단, 거인의 어깨위에 올라가는 수고는 해야겠죠?

그렇기 때문에 Framework이 중요합니다. 이 Framework은 기술지향적인 면이 많지만, 선택에 신중을 기한다면 많은 도움을 얻을 수 있습니다. 특히 최근에 나오는 Web Framework의 경우 몇 년간의 웹 개발 전문가들의 Know-how가 축적된 것들이어서 일반 개발자가 고민하지 못하는 기능까지도 포함되어 있습니다. 거인의 어깨 위에 올라가는 수고처럼, 여분의 시간으로 Framework을 배워서 업무에 사용할 수 있다면 많은 것을 얻을 수 있을겁니다.

그러나 한가지 잊지 말아야할 것은 Framework을 배우는 목적입니다. 난쟁이가 거인의 어깨 위에 올라가는 이유는 더 멀리, 더 많은 것을 보기 위해서입니다. 난쟁이가 많은 것을 얻을 수 없다면, 당장 거인의 어깨 위에서 내려와야 합니다. 마친가지로 Framework을 배우는 가장 큰 목적은 일을 효율적으로 하기 위함입니다. 그러기 위해서 Framework은 하나의 수단일 뿐이죠. 그렇기 때문에 많은 것을 얻을 수 없다면 과감히 해당 Framework을 버리는 용기도 필요합니다. (올라가기가 힘들기 때문에 한번 오를 때 신중을 기해야겠죠.)

------------------------------------------------------------------------------------

요즘 회사에서 프로젝트 진행하면서,

기존의 소스를 수정하면서(뜯어 고치며라는 표현보다는 아주 적절한 것 같다.), MVC Model에 대해서 고민하면서 MVC로 쪼개어 보았다가, M/VC구조로 결국 결정지어서 가고 있다.
내 맘대로 하는 게 아닌가 하는 생각이 들지만... -ㅅ-)a



예전에는 잘 몰랐던 Web Programming에서의 Design Pattern에 대해서 이것저것 많이 생각하게 된다. PHP5에 이르러 OOP적 지원이 많아서, 공부할 게 많아서 흥미롭다.

사무실에서 쓰는 Wiki에서 Advanced PHP Programming에 대해서 정리 중인데, 조만간 Publishing을 해야 할텐데, 귀차니즘의 압박으로 언제 Open될지 잘 모르겠다.

어쨌든, 자료수집을 위해서 구글링을 하다보면 우리나라에서의 PHP지위가 낮다는 생각을 한다. 커뮤니티 사이트에 가도, 고급 주제를 다루는 일이 거의 없는 것 같다. 요즘은...
(우리나라의 커뮤니티 사이트에서 Design Pattern 따위를 검색해도 걸리는 글의 작성년도를 보면 02~03년대가 많다.)

결론은 조만간 MVC Model 적용에 관해서 자료 모은 것을 Open할 준비를 해야겠다.
(위 그림도 자료 모으면서 발견한 정말 이해가 쏙쏙 들어오는 MVC Model 그림이다. ㅎㅎ)
-ㅅ-)/

------------------------------------------------------------------------------------

PHP5 web framework인 symfony를 공부하는 중 작성한 글을 연재하려고 합니다. 소개에서 부터 설치, 프로젝트 시작하기 그리고 실전 프로젝트까지 계획하고 있습니다. 나름대로 명분을 위해 Why MVC Framework 부터 시작합니다. ;-)

About Framework
프로그래밍 언어의 최고 메카니즘으로 인식되고 있으며, 개발 패턴의 많은 부분을 자동화 할 수 있다. VC++의 MFC, 델파이/BC++의 VCL, IBM의 Notes, C++ Network Framework ACE, X-Window의 KDE, GNOME등의 큰 것에서 부터 prototype 이라는 _javascript framework까지 널리 이용되고 있으며, 최근의 웹 프레임워크들은 Rapid Development와 함께 웹 개발의 새로운 패러다임으로 떠 오르고 있다. Best Practices가 녹아 있는 프레임워크가 쏟아져 나오고 있으니 그 중 잘 설계되어 뛰어난 확장성과 기능을 제공하는 것을 선택하는 안목만 있으면 된다. 물론 프레임워크를 사용하려면 초기 교육에 투자되는 비용이 많다. 그러나 그것으로 유지보수, 재사용성, 생산성등의 몇 마리 토끼를 동시에 잡을 수 있음은 충분히 매력적이라 할 수 있다.

About MVC
데이터 프로바이더에 대한 Model, 도메인 또는 비즈니스 로직에 대한 Controller, 사용자 인터페이스에 대한 View로 어플리케이션을 3가지 레이어로 구분하는 설계 방식이다.

객체지향프로그래밍에서, MVC란 사용자 인터페이스를 성공적이며효과적으로 데이터 모형에 관련 시키기 위한 방법론 또는 설계 방식중 하나이다. MVC 형식은 목적 코드의 재사용에 유용한 것은물론, 사용자 인터페이스와 응용프로그램 개발에 소요되는 시간을 현저하게 줄여주는 형식이라고 많은 개발자들이 평가하고 있다.

terms MVC

About MVC Framework
MVC는 Framework의 개념이 나오기 전부터 Procedure-oriented, Structural,Object-oriented, Component-based Development 프로그래밍등에서 널리 사용 되었다. 최고의 메소드와 최고의 메카니즘의 만남이라고 할 수 있다.

------------------------------------------------------------------------------------------

MVC 모델을 기반으로 PHP5로 개발된 오픈소스 웹 프레임워크 이다. 몇몇 활동적인 사이트에서 시도한 최고의 방식을 기반으로한 웹 개발로, 생산성 및 유지보수의 향상과 소모적인 반복 코딩작업을 줄여 즐거움을 얻을 수 있다.

PHP 프로젝트에서도 Rails 또는 Django나 유사한 프레임워크가 주는 이점을 얻을 수 있다.

• 특징

1. 간단한 템플릿과 도우미(Helpers)
2. 캐시 관리
3. 다중 환경 지원 (Dev, Prod)
4. 배포 관리
5. 기본 골격 (CRUD/Admin generator)
6. 스마트 URLs (routing policy)
7. 다국어 환경 지원
8. 객체모델과 MVC 분리
9. AJAX 지원

• 구성

1. Pake (php5 project build system) : 프로젝트 시작과 기본 골격등을 위한 자동화 빌드툴 (make의 개념)
   
2. Creole : Propel의 서브 프로젝트로 데이터베이스 추상화 레이어로 사용
3. Propel (full-service object persistence and query toolkit for PHP) : DAO나 ORM과 같은 개념이고 데이터 프로바이더의 모델과 컨트롤러의 객체화에 사용
4. YAML : 텍스트로 된 계층적 기반의 구조화된 데이터 포맷이고 기계와 사람 모두에게 용이한 접근 제공 (better than xml)
5. Mojavi : 다른 PHP MVC Framework이고 MVC 모델 레이어에 일부 코드 사용
6. 그리고 Symfony (오픈소스가 오픈소스를 이용한 아름다운 결과물이라 생각됨)
   

손쉬운 설치를 위해 아주 조금의 필수 조건이 있으며 설정은 거의 없다. 단지 웹서버와 PHP5가 설치된 Unix 혹은 Windows 가 필요하다. 대부분의 데이터베이스 시스템과 호환이 되고 프로바이더 추가에 대한 부담이 적은 편이다. 그리고 호스팅 비용을 제외하면 추가 비용이 발생하지 않는다.

Symfony는 PHP 유저가 사용하기 매우 쉽고 친숙하다. 그리고 인터넷 어플리케이션의 디자인 패턴 학습 부담을 하루 미만으로 줄여준다. 말끔한 디자인과 코드 가독성은 정체가 짧도록 유
지한다. 개발자는 어플리케이션 로직과 수많은 XML 설정 파일들의 작성에 버려지는 시간을 집중하여 DRY, KISS 또는 XP philosophy와 같은 애자일 개발 원칙을 적용할 수 있다.

Symfony는 기업에 맞는 강력한 어플리케이션이 목표이다. 이것의 의미는 외부 라이브러리 디렉터리 구조로 부터 유저가 설정 이상의 제어를 가지고 거의 모두가 최적화 될 수 있다는 것이다.

MIT 라이센스로 배포되며, 프랑스의 Sensio 라는 웹에이전시가 스폰서 해주고 있다.

p.s symfony book의 About Symfony를 대충 번역하여 구성쪽 내용을 추가 하였습니다.

---------------------------------------------------------------------------------------------

3가지 설치 방법중 수동설치를 제외한 sandbox와 PEAR Package 설치 및 Apache와 PHP 설정을 살펴 본다. 이 후 모든 설명은 PEAR Package를 기준으로 하지만 sandbox도 적용이 가능하다.

sandbox 설치
필요한 모든 파일과 라이브러리 그리고 빈(empty) 프로젝트가 포함된 압축 파일이고 원하는 곳에 압축을 푸는 것 만으로 설치가 끝난다. cache와 log 디렉터리 퍼미션을 0777로 변경해 줘야 한다. 웹서버 DocumentRoot에서의 작업으로 가정하고, 작업 후 http://hostname/sf_sandbox/web 가 기본 접속 주소가 된다.
The World Best Coder의 PHP5 Framework : symfony 시작하기(install sandbox)

[g@g2 htdocs]$ wget -q http://www.symfony-project.com/get/sf_sandbox.tgz
[g@g2 htdocs]$ tar zxf sf_sandbox.tgz
[g@g2 htdocs]$ cd sf_sandbox
[g@g2 sf_sandbox]$ chmod 777 log cache

PEAR Package 설치
PEAR 라이브러리로 설치하는 것으로 시스템 차원에서 symfony를 지원할 수 있고, project build system을 사용해서 원하는 만큼의 프로젝트를 만들 수 있다. CORE 파일들은 PEAR에 설치된 것을 사용하여 업그레이드의 용이성과 손쉬운 사용등이 가능하다. 1.4.0버전 이상의 PEAR가 필요하며, 먼저 PHP 설정이 필요하다. 본 설치는 symfony 자체의 설치이고 실제 사용을 위해서는 프로젝트 초기화를 해야 한다.

$ pear upgrade PEAR
$ pear channel-discover pear.symfony-project.com
$ pear remote-list -c symfony
$ pear install symfony/symfony
$ pear install http://phing.info/pear/phing-current.tgz

Apache 설정 (httpd.conf)
Smart URLs를 위한 mod_rewrite 사용을 허용하고 기본 웹 라이브러리 디렉터리를 /sf 로 Alias 한다. DocumentRoot를 루트 디렉터리 아래의 htdocs로 가정한다. 웹 브라우저에서는 symfony 프로젝트의 web 디렉터리에 있는 index.php등의 front controller에만 접근을 하면 되기 때문에 DocumentRoot를 /htdocs/sf_sandbox/web 이나 /htdocs/web 등으로 바꿔 줄 수도 있다.

<Directory "/htdocs">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>

<Directory "/usr/local/share/pear/data/symfony/web/sf">
AllowOverride All
Allow from all
</Directory>

Alias /sf /usr/local/share/pear/data/symfony/web/sf

PHP 설정 (php.ini)
symfony는 register_globals와 magic_quotes_gpc를 사용하지 않으며, PEAR Package 설치를 위해서 memory_limit를 수정해 주고, PEAR 라이브러리 사용을 위해서 include_path를 추가해 주어야 한다.

register_globals = Off
magic_quotes_gpc = Off
memory_limit = 64M
include_path = ".:/usr/local/share/pear"

------------------------------------------------------------------------------

구조
symfony는 Model과 View를 제외하고 project / application / module / action 의 계층적 구조를 가지며 각 단계별로 config가 존재한다. 하나의 웹 서비스를 개발할 때 하나의 project, 사용자와 관리자가 구분되는 두개의 application, 회원가입 / 회원관리 / 게시판등 단위 프로그램인 module 그리고 module의 최종 단위 프로세스인 action들로 이루어 진다고 볼 수 있다. (action의 예로 게시판의 글쓰기, 글읽기,글삭제, 글수정, 글목록등을 들 수 있다.)

초기화
가장 먼저 해야 하는 것으로 원하는 빈 디렉터리에서 아래 명령을 수행한다. 실제로는 PEAR에 있는 빈(empty) 프로젝트를 복사하고 몇가지 기본 설정을 해 준다. 아래 명령의 마지막 gogpp는 프로젝트명이 된다.

$ symfony init-project gogpp
$ symfony init-app default (empty application 생성)
$ symfony init-module test (empty module 생성)

위 명령을 수행하면 web 디렉터리 아래에 default.php 와 default_dev.php 라는 두개의 Front controller이 생기게 된다. DocumentRoot에서 작업을 했다면 http://hostname/web/default.php/test 나 http://hostname/web/default_dev.php/test 로 모듈에 접근 할 수 있다. 3편에서도 얘기 했지만 Apache DocumentRoot의 조정과 symfony 설정을 통해 web/default.php 라는 의미없는 주소영역은 제거할 수 있다. (settings.yml의 no_script_name을 on)

설정 (YAML사용)
초기화를 위와 같이 했다면 각 단계별로 다음과 같은 config 가 존재한다.

1. config (project) : 데이터프로바이더에 대한 설정
2. apps/default/config (application) : 캐시, 다국어, 로깅, 라우팅, 보안, 환경값등에 대한 전역 설정
3. apps/default/modules/test/config (module) : application보다 작지만 겹치는 부분이 있는 로컬 설정

Front controller
모든 웹 요청은 기본 어플리케이션과 실행 환경, 디버그 설정 정보를 가진 하나의 프론트 컨트롤러에 의해 제어된다. 설정 정보에따라 다양한 동작환경 구현이 가능하다. 기본적으로 호출되는 프론트 컨트롤러는 index.php 이며 web 디렉터리 아래에존재한다. (웹서버의 DirectoryIndex에 따라 달라질 수 있다.)

define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'default');
define('SF_ENVIRONMENT', 'dev');
define('SF_DEBUG', true);

Multi environment & Debugging
Front controller에는 SF_APP, SF_ENVIRONMENT, SF_DEBUG 상수가 선언되어 있는데 이 값을 조정하여 symfony 특징중 하나인 multiple environments support가 가능하다. SF_APP는 기본 application을 지정하고 SF_DEBUG는 디버깅 지원을 설정한다. 특히 SF_ENVIRONMENT를 통해 프론트 컨트롤러 별로 기능을 on, off 하거나 다르게 동작하도록 설정 할 수 있다. 예를 들어 index_dev.php 에서만 특정기능을 활성화 한다던지 다른 데이터베이스 접속등을 설정 할 수 있다. 또 Application의 settings.yml을 통해 프론트 컨트롤러에 따라 혹 발생할 수 있는 에러를 숨기거나 로깅 레벨의 조정, 기본 로딩 모듈의 조정등도 할 수 있다. 이러한 설정으로 제품과 개발 환경을 한 곳에서 구현 할 수 있어, 강력한 디버깅 환경 구축이 가능하다.

Multi environment 관련 설정

• 기본적으로 prod와 dev 환경설정으로 구분된 프론트 컨트롤러
• 프론트 컨트롤러에 따른 logger.yml과 settings.yml (no_script_name, error_reporting, web_debug)

Debugging 관련 설정

• 프론트 컨트롤러의 SF_DEBUG 상수
• 어플리케이션 logger.yml 설정파일
• 어플리케이션 settings.yml 설정파일의 error_reporting, web_debug

settings.yml

prod:
.settings:
no_script_name: on
# suffix: .html

dev:
.settings:
# E_ALL | E_STRICT = 4095
error_reporting: 4095
web_debug: on
cache: off
stats: off
no_script_name: on
etag: off
# suffix: .html

test:
.settings:
# E_ALL | E_STRICT & ~E_NOTICE = 2047
error_reporting: 2047
cache: off
stats: off
web_debug: off
no_script_name: off
etag: off

all:
# .actions:
# default_module: default
# default_action: index
#
# error_404_module: default
# error_404_action: error404
#
login_module: user
login_action: login