오래전에 제로보드라는 것이 있었다.
지금의 XpressEngine의 전신이라 할 수 있는데, 당시에는 대부분의 사이트들이 제로보드로 만들어졌다고 할 수 있다.
처음 PHP를 공부할때 제로보드는 좋은 교재였다.
독학으로 검색해가며, 여러 가지 게시판 프로그램의 소스를 분석하고 나름 기술 트렌드를 따라 하려 노력했었다.
처음 단독, 혼자서 지역 커뮤니티 사이트를 만들때 함수보다는 클래스, OOP를 적용하여 만들었고 싱글톤이라는 디자인 패턴도 적용했었다.
그렇게 그 커뮤니티 사이트는 게시판, 중고장터, 중고차 정보, 부동산 정보, 지역 상가 정보, 회원 개인의 일정, 메모, 미니 홈페이지 등의 기능을 만들어 가면서 의도치는 않았지만, 필요에 의해서 코드들이 구조화되고 그룹화되어 프레임워크 개념이 어느 정도 담겨 있게 되었다.
그 후, 보다 향상된 나만의 프레임워크를 만들고자 했으나, 이런 저런 핑계로, 아니 실력의 문제로 미루고 미루어 왔다.
그렇게 시간이 흘러 그누보드를 사용해 봤고, 코드이그나이터(codeigniter) 등을 사용해보고, 다른 프레임워크도 조금씩 분석도 해봤다.
공개된 프레임워크(오픈소스)는 강력하고 편리하지만 항상 나만의 프레임워크를 만들어야 한다는 생각은 계속 해왔다.
이제 핑계는 접어 두고 실행에 옮기기로 했다. 얼마나 걸릴지 모르지만, 얼마나 독창적일지는 모르지만,
우선 프레임워크 이름은 "ZOO"로 정했다.
아니 오래전부터 그렇게 정했었다. ZOO = 동물원에는 관리사무소가 있고 여기에 다양한 직원들이 프레임워크가 된다.
동물들을 서비스라 하면 프레임워크는 먹이를 주는 사육사, 건강을 돌보는 수의사, 훈련을 시키는 담당자를 말한다.
이렇게 프레임워크 기반으로 다양한 서비스를 만들어 갈 수 있기를 바라는 마음에 ZOO 라고 정했다.
ZOO의 목표, 개발 방향은 아래와 같이 정했다.
- 유연성
유연해야 한다. 유연하다는 것은 복잡해질 수도 있고 어려워질 수도 있다. 하지만 다양한 서비스를 지원하기 위해서는 유연해져야 한다.
특히 뷰, 프런트엔드와는 유연해져야 한다. 그래서 템플릿의 사용 여부는 사용자의 몫으로 넘기기로 한다. - 단순성
유연하면서 단순하게 만드는 것은 어렵다. 하지만 코드 단위는 단순해야 한다. - 명확성
유연하고 단순하게 할려면 규약이 명확해야 한다. 유연함은 규약 위에서만 허용되어야 한다.
프레임워크 사용에 있어서 의문이 들게 하면 안 된다. - HMVC
나는 MVC 보다는 HMVC를 선호한다. 선호, 취향의 문제라기보다 MVC로 하다 보면 라이브러리들이 흩어지곤 하는데 그게 싫다. - 4단계 호출 주소체계
주소체계는 domina.com/module/[sub_module]/controller/method 최대 4단계로 호출이 가능하다. - NAMESPACE 사용
CI의 아쉬운 점은 NAMESPACE 지원이 안된다는 것이다. 명확성을 위해서도, 단순성을 위해서도 NAMESPACE를 사용하는 것이 좋다. - MySqli & PDO
DB는 MySqli와 PDO를 지원할 것이고 DB 클래스는 CI의 DB클래스의 코드를 많이 참고할 예정이다. 다를 부분보다 DB는 신경 써야 할 것들이 상당히 많다. 특히 각 테이블에 해당하는 Scheme 클래스 객체를 생성하여 CRUD를 관리하게 될 것이다. - 디렉터리 구조
대략적인 구조는 아래와 같이 하겠지만 만들어 가면서 변경될 거 같다.
html
- ZOO
- apps
- boards (앱(모듈) 폴더)
- models (모델 파일 폴더)
- configs (설정 파일 폴더)
- views (뷰 파일 폴더)
- commons (공통 라이브러리 폴더)
- classes (공통 클래스 파일 폴더)
- helpers (헬퍼 파일 폴더)
- upload
벌써부터 머리가 아파온다. 어깨가 뻐근하다.