무하프로젝트

Git 저장소 분석

- Git 저장소는 아래와 같은 구조로 구성되어있다.

1. Working 영역(작업 폴더)

- "git init" 명령 실행 후 ".git" 파일이 저징되어 있는 위치를 가리킨다.

2. Staging 영역

Working 영역(작업 폴더)에 임의의 파일(Readme)을 생성 후 "git add ." 명령을 통해 Staging 영역으로 추가 시킨다.

또한, Working 영역의 Readme 파일은 "Blob" 형식으로 변환되어 아래 경로(.git/objects/3e/d8....79)에 저장되며, 파일의 실제 내용은 "Zlip(데이터 압축 라이브러리의 일종)"으로 압축되어 있다.

git add . 명령은? 

- Git로 하여금 앞으로 이 파일을 Tracking 하겠다는 선언이며, 다른 VCS(Version Control System) 시스템과는 달리 "commit" 단계가 아닌 "add" 단계에서 저장소에 파일이 생성되는 것을 볼 수 있다.

3. Repository 영역

"git commit" 명령을 통해 이전 Staging 영역에 등록된 리스트를 참조(add 명령을 통해 이미 Staging 영역에 파일이 등록되어 있기 때문)하여 새로운 "commit object"를 생성한다.

또한, 생성된 "commit object"는 아래 경로(.git/objects/48/c468937...72)에 저장되며, "Zlip"을 통해 압축된 내용을 확인 시, 아래와 같이 "Tree, Author, Committer, Commit msg" 가 담긴 내용을 확인할 수 있다.

.git/refs/heads/master 파일은 아래와 같이 "486893....72" commit object 객체를 가리키고 있다.

4. 두 번째 commit object 생성 후 HEAD 변화

- 위 과정을 통해 두 번째 "commit object" 까지 생성하게되면, 이전 "486893....72" 객체를 가리키던, .git/refs/heads/master 파일은 새로운 commit object인 "786481...60" 객체를 가리키게 된다.

이는 "git branch -v" 명령을 통해서도 확인 가능하다.

5. Git 저장소 내부 파일의 Status Life Cycle은 아래 같으며, 보시는 바와같이 파일의 Untrancked 시점과 Tracked 시점은 Git add 전/후로 나눠진다.(중요!!)

출처: http://www.slideshare.net/andabi/git-16126636

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)

만약 JQuery와 같이 외부에서 공개된 오픈 소스 라이브러리들을 사용하고자 할때 보통 우리는 아래와 같은 방법으로 해당 정적 리소스들을 Include 시킨다.

< script type="text/javascript" defer="defer" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js">

하지만 만약 어플리케이션의 도메인이 HTTPS(보안 통신 프로토콜(SSL 적용))를 사용하는 경우라면, 위 코드와 같이 삽입할 경우 아래와 같은 문제가 발생한다.

- 아래 그림에서 보시다시피 크롬 개발자 도구의 네트웍 탭 상에 Include 시킨 리소스(jquery.min.js)가 없는 것을 확인할 수 있다.

- 또한, 콘솔 탭을 살펴보면 아래와 같은 오류(안전하지 않은 컨텐츠이기 때문에 가져올 수 없다?)를 확인할 수 있다.

위와 같은 문제를 간단히 해결하기 위한 방법으로 아래 코드와 같이 Include 블럭 속성 값(url)을 넣어준다. 

- 이와 같이 정의할 경우 해당 어플리케이션의 HTTP 프로토콜에 따라 속성 값의 Protocol이 자동 변환되기 때문이다.

즉, 어플리케이션 상의 프로토콜이 HTTP라면 "http"로 HTTPS라면 "https"로 자동 변환되는 것이다.(P.S: IE6 ~ IE10 or 표준 브라우저 호환)

< script type="text/javascript" defer="defer" src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js">

- 아래 그림은 위 코드 블럭을 적용한 결과이다.

- 만약 리소스들을 Include 하는 파일(html)이 로컬 웹 서버를 거치치 않는 방식(직접 파일 열기)일 경우 위와 같은 선언 방식(//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js) 으로는 해당 리소스들이 열리지 않는다.

즉, 간단한 테스트를 위해 생성한 html 파일을 위와 같은 방법으로 리소스들을 인클루드 시킬 경우 에러가 발생하니 사용 시 주의해야할 필요가 있다.

PS: 또한, 개발자 도구를 통해 살펴본 리소스들의 주소는 아래와 같다는 것을 알수 있다.

file://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js

- 출처: @insanehong님

참고사이트:

https://developers.google.com/speed/libraries/devguide

http://hoons.net/Blog/View/111726

1. MVC 패턴이란?

MVC 패턴이란 하나의 어플리케이션을 크게 Model, View, Controller이라는 세 영역으로 구분하고 각 영역간의 코드 결합도를 최소화 시키는 개발 패턴 중 하나이다.

- 다시말해 패턴의 주요 목적은 Model과 View 영역간의 코드 결합도를 최소화 시키는데 있다고 볼 수 있다.

2. 영역간의 역활 정의

Model: 어플리케이션에 비지니스 로직과 사용되는 데이터를 다루는 영역이다.

- 보통 비지니스 로직에 필요한 데이터는 해당 DB에 의해 관리되고, 그 데이터를 다루는 연산은 SQL 문법을 통해 구현된다.

View: 최종 사용자에게 보여줄 프리젠테이션 로직을 담당하는 영역이다.

- 웹으로 말하자면 정적 리소스로는 HTML, 동적 리소스로는 ASP, PHP, JSP 등의 파일로 나뉠 수 있다.

Controller: 기존 MV 패턴에서 View가 맡아하던 Model 영역과의 일부 로직들을 Controller 영역으로 대체하여, Model과 View 영역간의 코드 결합도를 줄여주는 영역이다.(결국 패턴의 궁극적인 목적을 이루기 위한 가장 중요한 영역이라고 볼 수 있다.)

3. 영역간의 진행 순서

사진출처: http://cheucheu.tistory.com/48

- 이전 MV 패턴과는 상대적으로 복잡한 구조를 지닌 것을 것을 볼 수 있으며, 패턴에 대한 진행 순서은 아래와 같다.

1. Client(최종 사용자)가 특정 Controller 영역을 호출한다.

2. 요청받은 Contoller 영역은 특정 Model 영역의 비지니스 로직을 호출해 그에 대한 수행 결과(보통 DB 연동을 통한 데이터들의 집합이다)를 반환받는다.

3. Controller는 Model 영역을 통해 반환받은 데이터들의 집합을, 특정 View를 호출해 클라이언트에게 응답(제공)할 UI를 만들도록 한다.

- 패턴 진행 순서: Controller >> Model >> Controller >> View

- 장점: 

1. 어플리케이션 유지보수 시 비지니스 로직에 대한 변경 사항이 많은 경우 추가되는 개발 비용이 현저히 내려간다.(Contoller 영역을 통해 Model과 View 영역간의 코드 결합도를 현저히 낮춤으로써 Model 영역의 비지니스 로직 변경 시 해당하는 View 영역의 변경 사항이 줄어든다.(하지만 이는 아래 단점에서도 볼 수 있듯이 Controller 영역을 어떻게 설계하느냐에 따라 크게 달라질 수 있는 부분이기도 하다.))

2. Contoller 영역을 통해 전체 어플리케이션 코드 관리가 용이해진다.(이는 위 장점과 마찬가지로 유지보수 시에 대한 또 다른 장점이며, 결국 이 또한 Model과 View 영역간의 코드 결합도를 낮춤으로써 나타나는 결과이다.)

- 단점: 

1. 이전 MV 패턴과는 달리 좀더 복잡한 개발 구조를 통해 초기 개발 비용이 올라간다.(단순히 생각해도 이전에 없었던 Contoller 영역의 추가로 인해 초기 개발 비용이 상승하는것은 너무도 당연한 일이다.  다시말해 영역들간의 좀더 세밀한 역활 분기로 인해 설계 및 작성해야 할 코드량이 많아진다는 것이다.)

2. 앞서 말했듯이 MVC 패턴의 복잡한 아키텍처로 인해 각 영역에 대한 재 사용성은 이전 MV 패턴에 비해 많은 부분 좋아졌지만, 그 만큼 새롭게 추가되는 Contoller 영역의 역활이 중요해졌으며, 만약 개발이 잘 못 되었을 경우 어플리케이션 전체에 미치는 악 영향이 매우 커질 수 있다.

4. JavaScript로 구현한 MVC 패턴의 예

- 화면 UI는 이전 MV 패턴과 동일하며, 아래 작성된 패턴에 대한 설명은 코드 상 주석으로 표기하였다.

참고 사이트:

MVC(Model / View / Controler) 패턴:

http://blog.naver.com/yellobox62?Redirect=Log&logNo=80048634644