[분류 전체보기]검색결과, 375건
- [AngularJS] REST API 통신(with Node.js) 2016.07.15
- [Node.js] socket.io를 활용한 웹채팅 구현 2016.07.15 5
- [AngularJS] Route 2016.07.14
- [AngularJS] Directive 2016.07.13
- [AngularJS] $scope과 controller-as 문법 2016.07.12
- [AngularJS] Module 2016.07.12
- [AngularJS] Two-way Data Binding 2016.07.10
- [AngularJS] MVC Pattern in Angular 2016.07.10
- [AngularJS] 일주일 탐방기 2016.07.06
- 그대는 어디에... 2015.10.08
- 데브옵스 처방전 2015.05.21
- Security Context Token(SCT) Expired on WCF 2015.03.03
- 개발자 칠거지악 2015.02.06
- 미스터 빈, 너로구나 2014.07.31
- 6하원칙 리더십 2014.07.09
AngularJS는 원격 서버와의 HTTP 기반 통신을 위해 $http서비스를 제공한다.
$http는 브라우저의 XMLHttpRequest 객체나 JOSNP를 이용하여 원격 서버와 통신하기 위한 AngularJS의 서비스다.
이번 글에서는, $http서비스를 이용한 비동기 통신의 기본적 샘플을 구현해 보겠는데, 서버는 간단히 REST API 구현이 가능한 Node.JS를 사용한다.
* 서버 측 코드
- 먼저 Node.JS 기반으로 동작하는 HTTP 서버를 생성한다. express와 bodyParser 등 확장 라이브러리를 npm을 통해 먼저 설치해 둔다.
서버는 간단한 REST 기반 API 3개를 정의하고 있다.
사용자 목록(/users)과 단일사용자(/users/사용자id) 에 대한 GET API와 사용자등록(/users)을 위한 POST API로 구성되어 있다. 파일을 server.js로 저장하고, 쉘을 통해 server.js를 실행한다.
나머지 사항은 주석을 보면 이해될 정도로 심플하다.
var url = require("url");
//post 데이터의 body 속성 접근 및 json파싱 위한 bodyParser 미들웨어 사용
var bodyParser = require("body-parser");
app.use(bodyParser.urlencoded({extended:true}));
app.use(bodyParser.json());
//루트에 대한 get 요청에 응답
app.get("/", function(req, res){
console.log("get:chatClient.html");
//최초 루트 get 요청에 해대, 서버에 존재하는 client.html 파일 전송
res.sendFile("client.html", {root: __dirname});
});
//GET API(http://127.0.0.1:3000/users), 전체사용자 목록
app.get('/users', function(req, res) {
//임의의 사용자 리스트 생성(실제 환경에서는 db 등 연동 결과로 생성)
var tempUsers = [{id:'park', city:'pusan'}, {id:'kim', city:'seoul'}];
//클라이언트에 반환
res.send(tempUsers);
});
//GET API(http://127.0.0.1:3000/users/1), 특정 사용자 id를 지정하여 한명의 사용자 정보 호출
app.get('/users/:id', function(req, res) {
//매개변수로 전달된 사용자 id 값 추출
var id = req.params.id;
//전달받은 사용자 id 그대로 다시 반환
res.send([{id:id, city:'pusan'}]);
});
//POST API, 새로운 사용자 생성
app.post('/users', function(req, res){
//POST 데이터로 넘어온 JSON 추출
var postData = req.body;
console.log(postData);
//클라이언트에 그대로 다시 반환(실제 환경에서는 db 삽입 등 작업)
res.send([postData]);
});
//3000포트로 http 서버 리스닝 시키기
app.listen(3000);
console.log("Listening on port 3000");
* 클라이언트 측 코드
- 자바스크립트와 HTML을 분리하면 좋지만, 글 작성 편의를 위해 하나의 파일로 만든다. 그리고 서버코드에서 지정한 대로, client.html로 저장한다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
//원격 서버 URL 지정
var url = "http://127.0.0.1:3000/users/";
//AngularJS 메인모듈 생성
var app = angular.module('myApp', []);
app.controller('userController', function($http) {
//현재 컨텍스트의 this 참조저장
var userCtrl = this;
//GET 요청
//'http://127.0.0.1:3000/users' 또는 'http://127.0.0.1:3000/users/특정ID' 형태의 rest api 호출
userCtrl.getUser = function(userID){
//사용자 id가 매개변수로 넘어온 경우 url에 id 매개변수 붙이기
var id = userID || "";
$http.get(url + id)
.then(function(response){
//응답 성공 시 실행
userCtrl.users = response.data;
userCtrl.response = response;
})
.catch(function(error){
//실패시 실행
console.log('오류 발생');
userCtrl.response = error;
})
.finally(function() {
//성공, 실패 어떤 경우에도 실행
console.log('finish getUser()');
});
};
//POST 요청
userCtrl.postUser = function(data){
//post로 보낼 json 데이터 임의생성
var postData = JSON.stringify({id:'newID', city:'newCity'});
//http 요청객체 생성
var req = {
method: 'POST',
url: url,
headers: { 'Content-Type': 'application/json; charset=UTF-8'},
data: postData
};
$http(req)
.then(function(response){
userCtrl.users = response.data;
userCtrl.response = response;
})
.catch(function(error){
console.log('오류 발생');
userCtrl.response = error;
})
.finally(function() {
console.log('finish postUser()');
});
};
});
</script>
<body>
<div ng-app="myApp" ng-controller="userController as userCtrl">
<button ng-click='userCtrl.getUser();'>1.GET</button>
<button ng-click='userCtrl.getUser("777");'>1.GET(using ID)</button>
<button ng-click="userCtrl.postUser();">1.POST</button>
<!-- 사용자 리스트 -->
<ul>
<li ng-repeat="user in userCtrl.users">
{{ user.id + ', ' + user.city }}
</li>
</ul>
<!-- 응답 객체 정보 출력 -->
<p>
response status: {{userCtrl.response}}
</p>
</div>
</body>
</html>
설명은 주석으로 충분한 듯 보이고, 실행화면은 다음과 같다.
- GET, http://127.0.0.1:3000/users/ 요청
- GET, http://127.0.0.1:3000/users/777 요청
- POST, http://127.0.0.1:3000/users/ 요청
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] 폼(form)과 유효성 검사 (0) | 2016.07.18 |
---|---|
[Node.js] CORS 설정(Cross Domain 요청 허용) (0) | 2016.07.15 |
[Node.js] socket.io를 활용한 웹채팅 구현 (5) | 2016.07.15 |
[AngularJS] Route (0) | 2016.07.14 |
[AngularJS] Directive (0) | 2016.07.13 |
재밌네... ㅎㅎ
별도의 비표준 플러그인 없이, 웹에서 채팅을 이렇게 쉽게 구현할 수 있는 시대라니...
6년전, 웹 소켓에 대해 나름 정리한 적이 있다.
이미 그 시대는 오래전(?)에 도래했건만, 개인적으로 방치해 두다가, 어제 밤 문득...
웹 소켓과 node.js를 사용해서 채팅 샘플을 구현해 보고 싶다는 생각이 스쳐 지나갔다.
socket.io라는 자바스크립트 라이브러리가 존재한다더니, 이건 뭐.. 다른건 볼 필요도 없네.
socket.io는 Node.js 기반으로 소켓 통신이 가능하도록 해 주는 확장 라이브러리인데, HTML5의 정식표준인 WebSocket을 지원하지만, 미지원 환경에 대한 호환성을 위해 Comet 같은 기술도 하나의 API로 추상화 시킨 양방향 통신 라이브러리이다.
socket.io는 WebSocket이 지원되지 않는 환경에서 실시간 양방향 통신을 구현하기 위해 다음과 같은 fallback 기술을 사용하고 있다.
- FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling
기본적으로 Node.js 설치해 주고, express와 socket.io를 npm을 통해 다음과 같이 설치한다.
- npm install express
- npm install socket.io
이제 환경 설정은 끝이다. 자바스크립트 기반 개발환경은 이렇듯 심플하다. 내가 좋아하는 이유 중 주요한 팩터이다.
* socket.io를 이용한 웹 채팅 구현하기
먼저 다음과 같은 3개의 파일을 준비한다.
1. chatServer.js
- 채팅 서버 역할을 하는 자바스크립트 파일로, Node.JS에 의해 호스팅되며 socket.io 라이브러리를 통해 소켓 서버를 구현한다. 또한 부가적으로 http 리소스 요청에도 응답할 수 있도록 한다.
2. chatClient.js
- 채팅 서버와 통신을 하는 클아이언트 자바스크립트 파일로, 역시 socket.io 라이브러리를 사용하며 채팅을 위한 간단한 DOM 조작을 수행한다.
3. chatClient.html
- chatClient.js가 정의된 html 파일이며, 채팅창과 텍스트 박스로 간단히 구성된 뷰를 제공한다.
먼저 chatServer.js 파일의 코드부터 보자.
var url = require("url");
//루트에 대한 get 요청에 응답
app.get("/", function(req, res){
console.log("get:chatClient.html");
//최초 루트 get 요청에 대해, 서버에 존재하는 chatClient.html 파일 전송
res.sendFile("chatClient.html", {root: __dirname});
});
//기타 웹 리소스 요청에 응답
app.use(function(req, res){
var fileName = url.parse(req.url).pathname.replace("/","");
res.sendFile(fileName, {root: __dirname});
console.log("use:", fileName);
});
//http 서버 생성
var server = require('http').createServer(app);
server.listen(3000);
console.log("listening at http://127.0.0.1:3000...");
//클로저를 사용해, private한 유니크 id를 만든다
var uniqueID = (function(){
var id = 0;
return function(){ return id++; };
})();
//서버 소켓 생성
var socket = require('socket.io').listen(server);
//소켓 Connection 이벤트 함수
socket.sockets.on('connection', function(client){
//클라이언트 고유값 생성
var clientID = uniqueID();
console.log('Connection: '+ clientID);
//서버 receive 이벤트 함수(클라이언트에서 호출 할 이벤트)
client.on('serverReceiver', function(value){
//클라이언트 이베트 호출
socket.sockets.emit('clientReceiver', {clientID: clientID, message: value});
});
});
다음으로 chatClient.js 소스이다.
//클라이언트 소켓 생성
var socket = io.connect('ws://127.0.0.1:3000');
//DOM 참조
var div = document.getElementById('message');
var txt = document.getElementById('txtChat');
//텍스트 박스에 포커스 주기
txt.focus();
//텍스트 박스에 이벤트 바인딩
txt.onkeydown = sendMessage.bind(this);
function sendMessage(event){
if(event.keyCode == 13){
//메세지 입력 여부 체크
var message = event.target.value;
if(message){
//소켓서버 함수 호출
socket.emit('serverReceiver', message);
//텍스트박스 초기화
txt.value = '';
}
}
};
//클라이언트 receive 이벤트 함수(서버에서 호출할 이벤트)
socket.on('clientReceiver', function(data){
//console.log('서버에서 전송:', data);
//채팅창에 메세지 출력하기
var message = '['+ data.clientID + '님의 말' + '] ' + data.message;
div.innerText += message + '\r\n';
//채팅창 스크롤바 내리기
div.scrollTop = div.scrollHeight;
});
};
마지막으로 chatClient.html 파일이다.
<script src="/socket.io/socket.io.js"></script>
<div id="message" style="background-color:#F5F5F5; width:400px; height:200px; OVERFLOW-Y:auto; word-wrap: break-word"></div>
<div id="chatInput">
메시지를 입력하세요 <input type='text' id='txtChat' name="txtChat">
</div>
* 실행흐름
1) 서버 실행
- Node의 쉘기능을 이용해 다음과 같이 chatServer.js를 실행한다. 실행하면 다음 그림과 같이 console 로그가 프롬프트 창에 찍힌다.
2) 클라이언트 실행
- 클라이언트에서는 단순히 브라우저로 지정된 url로 접근하기만 하면 된다.
브라우저로 chatServer.js 서버로 접속하면, 루트 get요청(http://127.0.0.1:3000)에 따른 chatClient.html 파일이 클라이언트로 다운로드 되고, 이 HTML파일이 브라우저에서 실행되면서 chatClient.js 파일에 대한 요청이 다시 이뤄져 자바스크립트 코드가 다운로드 되고 실행된다. 이 클라이언트 자바스크립트가 실행되어 소켓서버와 클라이언트는 서로 연결이 이뤄진다.
다음 그림은 브라우저에서 해당 url로 접근했을 때 서버측 로그화면이다.
* 결과화면
- 총 4개의 사용자가 접근하는 시나리오로 가정하여, 4개의 브라우저를 동시에 사용한다. 각 브라우저에서 해당 url로 접근하고 각자 채팅을 해 본다. 이때 각 클라이언트 구분은 서버측 코드에서처럼 임의의 순처적 고유값을 부여한 숫자로 사용한다.
다음 화면은 브라우저 4개를 띄우고, 채팅을 해본 모습니다. 혼자놀기에 좋다 ㅡ,ㅡ;
지금까지 알아본 샘플 채팅은 채팅 구현을 위한 가장 기본적이면서도 필수적으로 구현되어야 하는 것들만 다뤘다. 실제 업무에서 채팅을 구현한다면 성능과 안정성 등을 위해 다양한 방어코드, 추가기능 코드, 최적화 기법 등의 추가 작업이 필요할 것이다.
기본적인 흐름과 코드를 알았으니, 살을 붙여 나가면 될 일이다.
'모바일 > Javascript' 카테고리의 다른 글
[Node.js] CORS 설정(Cross Domain 요청 허용) (0) | 2016.07.15 |
---|---|
[AngularJS] REST API 통신(with Node.js) (0) | 2016.07.15 |
[AngularJS] Route (0) | 2016.07.14 |
[AngularJS] Directive (0) | 2016.07.13 |
[AngularJS] $scope과 controller-as 문법 (0) | 2016.07.12 |
AngularJS는 URL기반 경로 탐색을 지원하는 라우트(route) 모듈을 제공한다.
라우팅 기능은 SPA(Single Page Application)를 지향하는 프레임워크에서 빠져서는 안되는 중요한 기능이며, 이미 그전의 많은 모바일 자바스크립트 프레임워크(jQTouch, jQuery Mobile, Sench Touch 등)에서도 제공되는 유용한 기능이다.
라우팅 기능은 다수의 사용자 화면(UI)을 가진 AngularJS 응용프로그램 구현 시 특히 유용한 기능으로 개별 사용자 화면을 서로 다른 HTML 파일로 만들고, URL주소에 따라 특정 화면으로로 이동시켜 주는 기능이다. 특히 SPA환경에서의 페이지 교체는 새로고침 없이 단일 페이지에서 HTLM Element의 교체로 이뤄져야 하는데 AngularJS는 이와 같은 기능을 route 모듈과 ng-view 디렉티브의 조합으로 가능케 한다.
라우팅 구현은 아주 심플하며, w3schools.com의 예제는 이를 잘 설명해 주고 있다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script src="//ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular-route.js"></script>
<script>
var app = angular.module("myApp", ["ngRoute"]);
app.config(function($routeProvider) {
$routeProvider
.when("/", {
templateUrl : "main.htm"
})
.when("/red", {
templateUrl : "red.htm"
})
.when("/green", {
templateUrl : "green.htm"
})
.when("/blue", {
templateUrl : "blue.htm"
});
});
</script>
<body ng-app="myApp">
<p><a href="#/">Main</a></p>
<a href="#red">Red</a>
<a href="#green">Green</a>
<a href="#blue">Blue</a>
<div ng-view></div>
</body>
</html>
먼저 라우팅 모듈이 정의된 angular-route.js에 대한 스크립트 참조를 추가하고, 메인모듈에 ngRoute서브모듈을 주입한다. 그리고 응용프로그램이 실제 동작하기 전에 수행되어야 할 설정옵션을 정의할 수 있는 module.config 메서드에 라우팅 기능을 추가한다.
$routeProvider는 라우팅 기능을 위해 AngularJS에서 기본적으로 제공하는 서비스이며, URL조건과 이에 대응하는 리소스 경로는 $routeProvider.when 메서드에 라우팅 설정 객체를 정의하는 방식으로 구현한다.
ngRoute 모듈을 이용한 라우팅은 ng-view 디렉티브와 연결된다. 라우팅 조건에 맞는 URL 요청이 들어오면 이에 대응하는 리소스이 내용(HTML페이지)을 불러와서 ng-view 디렉티브 동적으로 삽입시킨다.
각각의 HTML 페이지는 새로운 URL요청에 따라 네트워크를 통해 다운로드 받게 되는데, 이때 대상 페이지가 새로고침(reload)되는 것이 아니라, 페이지의 특정 영역(ng-view)에 불러온 HTML 내용을 삽입하는 방식으로 동작하기 때문에 SPA(Single Page Application) 구현이 가능하게 된다.
URL 링크는 #red와 같은 형태로, 해시(#) 기호를 이용하여 작성한다.
* 대체 라우트 지정
- 요청된 URL에 대한 라우팅 정의가 없을 경우, $routeProvider 서비스의 otherwise 메서드로 대체 라우트를 정의할 수 있다. 다음의 코드는 일치하는 URL이 없을 경우 루트(/)로 이동하도록 구현한 것이다.
$routeProvider
.when("/red", {
templateUrl : "red.htm"
})
.otherwise({redirectTo: '/'})
});
* Controller와 함께 사용하기
- 라우팅된 페이지 역시 AngularJS의 영역에 포함된 HTML영역이기에 일반적인 Controller 사용형태를 그대로 구현할 수 있다. 다음 예제는 라우팅에서 Controller를 사용해 각 뷰에 해당하는 컨트롤러를 정의하고 Controller-as 문법을 사용한 코드이다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script src="//ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular-route.js"></script>
<script>
var app = angular.module("myApp", ["ngRoute"]);
app.config(function($routeProvider) {
$routeProvider
.when("/Page1", {
templateUrl : "Page1.html",
controller : "Page1Controller",
controllerAs: "page1Ctrl"
})
.when("/Page2", {
templateUrl : "Page2.html",
controller : "Page2Controller",
controllerAs: "page2Ctrl"
});
});
app.controller("Page1Controller", function(){
var page1Ctrl = this;
page1Ctrl.msg = "Page1 Controller Property";
});
app.controller("Page2Controller", function(){
var page2Ctrl = this;
page2Ctrl.msg = "Page2 Controller Property";
});
</script>
<body ng-app="myApp">
<a href="#Page1">Page1</a>
<a href="#Page2">Page2</a>
<div ng-view></div>
</body>
</html>
- Page1.html
<p>{{page1Ctrl.msg}}</p>
- Page2.html
<p>{{page2Ctrl.msg}}</p>
* 매개변수와 함께 사용하기
- 지금까지 구현한 예제에서는 실제 리소스 URL만 지정해서 라우팅을 구성하였다. 실무 환경에서는 번번히 URL에 매개변수가 따라 붙는다. 예를 들어 다음과 같이 특정 게시물 ID를 매개변수로 지정해서 해당 게시물로 바로 접근하는 URL을 만들 수 있다.
- http://yourdomain/board/10 (10번 게시물에 대한 URL 스킴)
AngularJS 라우팅 시스템에서는 URL의 매개변수 정보를 얻기 위해서 $routeParams 를 제공한다.
라우팅 경로 설정시 ':(콜론)' 을 사용해서 매개변수명을 추가하고, 컨트롤러에 $routeParams 주입하여 scope객체에 매개변수 값을 노출시킬 수 있다.
다음 코드는 바로 직전 예제에서 매개변수 처리를 추가한 코드이다.
<!DOCTYPE html>
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script src="//ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular-route.js"></script>
<script>
var app = angular.module("myApp", ["ngRoute"]);
app.config(function($routeProvider) {
$routeProvider
.when("/Page1/:param", {
templateUrl : "Page1.html",
controller : "Page1Controller",
controllerAs: "page1Ctrl"
})
.when("/Page2/:param", {
templateUrl : "Page2.html",
controller : "Page2Controller",
controllerAs: "page2Ctrl"
});
});
app.controller("Page1Controller", function($routeParams){
var page1Ctrl = this;
page1Ctrl.msg = "Page1 Controller Property";
page1Ctrl.param = $routeParams['param'];
});
app.controller("Page2Controller", function($routeParams){
var page2Ctrl = this;
page2Ctrl.msg = "Page2 Controller Property";
page2Ctrl.param = $routeParams['param'];
});
</script>
<body ng-app="myApp">
<a href="#Page1/param1">Page1</a>
<a href="#Page2/param2">Page2</a>
<div ng-view></div>
</body>
</html>
- Page1.html
<p>{{page1Ctrl.msg}}</p>
<p>{{page1Ctrl.param}}</p>
- Page2.html
<p>{{page2Ctrl.msg}}</p>
<p>{{page2Ctrl.param}}</p>
URL에서 매개변수 정보를 추출하기 위해 보다 직관적인 $routeParams를 사용했지만, 다음과 같이 $route를 이용해도 동일하게 처리 가능하다
var page1Ctrl = this;
page1Ctrl.msg = "Page1 Controller Property";
page1Ctrl.param = $route.current.params['param'];
});
* 로딩 중 이미지 표시하기
- 이쯤되면, 왠만한 웹개발자들은 한가지 부가기능이 필요하다는 것을 느낄 것 이다. 바로 '로딩 중' 처리이다. 라우팅을 통해 HTML페이지를 내부적으로 요청할 때 지연이 발생하지 않는다는 보장을 할 수 없다. 페이지 로딩의 지연은 페이지 자체의 크기(무게) 때문일 수도 있고, 인터넷 네트워크 통신지연 때문일 수도 있다. 또한 라우팅 시 뷰가 표시되기 전에 반드시 먼저 선행되어야 하는 라이트 의존성 작업이 클 경우에도 지연이 발생할 수 있다.
UX 측면에서 보면, 발생 가능한 정상적 지연상황을 사용자에게 알려주는 것이 좋다. 즉 우리가 흔히들 사용하는 '로딩중' 이미지를 표시해 주면 좋을 것이다.
AngularJS 라우트에서는 이러한 처리를 지원하기 위해 라우트 이벤트를 제공한다. 라우트 이벤트를 통해 라우트가 시작되는 시점과 종료하는 시점에 특별한 작업을 추가할 수 있다. 우리는 여기에 로딩중 이미지를 표시해 볼 것이다.
먼저 다음과 같이, 메인모듈의 run 메서드를 작성한다. 로딩중 이미지는 응용프로그램 전역적으로 적용되어야 하는 기능이기 때문에 모듈의 run 메서드를 이용한다.
$rootScope.$on('$routeChangeStart', function(e, curr, prev){
$rootScope.IsLoading = true;
});
$rootScope.$on('$routeChangeSuccess', function(e, curr, prev){
$rootScope.IsLoading = false;
});
});
$rootScope 객체를 통해, routeChangeStart 이벤트와 routeChangeSuccess 이벤트 리스터를 등록한다.
이 이벤트 핸들러 함수들은 이벤트 객체와 현재페이지, 이전페이지 객체가 매개변수로 제공된다.
우리는 단순히 로딩중 이미지만 표시하면 되기에 특별히 매개변수를 사용하지는 않지만, $rootScope 객체에 IsLoading라는 임의의 속성을 추가시킨다. 이렇게 하면 응용프로그램의 뷰 어느 영역에서든 IsLoading 속성에 접근할 수 있게 된다.
다음으로, HTML 내용을 다음과 같이 작성한다. 로딩중 이미지가 표시될 영역을 추가하고 ng-class에 해당 CSS 클래스와 앞서 추가한 $rootScope 객체의 Loading 속성 값(true or false)을 매칭시킨다.
<a href="#Page1/param1">Page1</a>
<a href="#Page2/param2">Page2</a>
<div ng-view></div>
<div class="loadingModal"></div>
</body>
</html>
마지막으로, CSS를 다음과 같이 작성한다. loader.gif 이미지는 미리 준비해 둔다.
overflow: hidden;
}
body.loading .loadingModal {
display: block;
}
.loadingModal {
display: none;
position: fixed;
z-index: 1000;
top: 0;
left: 0;
height: 100%;
width: 100%;
background: rgba(244, 249, 251, 0.80) url(loader.gif) 50% 50% no-repeat;
}
다음은 로딩중 샘플의 전체 코드이다.
<html>
<style>
body.loading {
overflow: hidden;
}
body.loading .loadingModal {
display: block;
}
.loadingModal {
display: none;
position: fixed;
z-index: 1000;
top: 0;
left: 0;
height: 100%;
width: 100%;
background: rgba(244, 249, 251, 0.80) url(loader.gif) 50% 50% no-repeat;
}
</style>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script src="//ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular-route.js"></script>
<script>
var app = angular.module("myApp", ["ngRoute"]);
app.config(function($routeProvider) {
$routeProvider
.when("/Page1/:param", {
templateUrl : "Page1.html",
controller : "Page1Controller",
controllerAs: "page1Ctrl"
})
.when("/Page2/:param", {
templateUrl : "Page2.html",
controller : "Page2Controller",
controllerAs: "page2Ctrl"
});
});
app.controller("Page1Controller", function($route){
var page1Ctrl = this;
page1Ctrl.msg = "Page1 Controller Property";
page1Ctrl.param = $route.current.params['param'];
});
app.controller("Page2Controller", function($routeParams){
var page2Ctrl = this;
page2Ctrl.msg = "Page2 Controller Property";
page2Ctrl.param = $routeParams['param'];
});
app.run(function($rootScope){
$rootScope.$on('$routeChangeStart', function(e, curr, prev){
$rootScope.IsLoading = true;
});
$rootScope.$on('$routeChangeSuccess', function(e, curr, prev){
$rootScope.IsLoading = false;
});
});
</script>
<body ng-app="myApp" ng-class="{loading:IsLoading}">
<a href="#Page1/param1">Page1</a>
<a href="#Page2/param2">Page2</a>
<div ng-view></div>
<div class="loadingModal"></div>
</body>
</html>
* 페이지 호출 대신, 내부 템플릿 사용
- 대부분 복잡한 사용자화면은 HTML를 분리시키고 라우트를 통해 페이지 호출하는 형태로 작성될 것이다. 그러나 간단한 내용이라면 굳이 HTML 페이지로 분리시키지 않고 바로 HTML값을 템플릿으로 지정할 수 있다. templateUrl 대신 template를 사용하면 된다.
* ngRoute 모듈의 한계
- 지금까지 AngularJS의 ngRoute 서브모듈을 이용해 라우팅 기능을 구현해 보았다. ngRoute 모듈은 라우팅을 위해 AngularJS에서 제공하는 기본 모듈로 한 페이지에 오직 한 개의 ng-view 디렉티브만 선언가능하다. 이는 내부적으로 라우트와 뷰 사이에 일대일 관계만이 성립되는 제약때문이다.
만일 여러개의 뷰가 중첩되거나 복잡한 레이아웃(다중뷰, 중첩뷰 등)으로 구성된 페이지에서 고릅 라우팅을 구현하고자 할 경우에는, ui-router 라이브러리를 이용할 것을 권장한다.
- https://github.com/angular-ui/ui-router
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] REST API 통신(with Node.js) (0) | 2016.07.15 |
---|---|
[Node.js] socket.io를 활용한 웹채팅 구현 (5) | 2016.07.15 |
[AngularJS] Directive (0) | 2016.07.13 |
[AngularJS] $scope과 controller-as 문법 (0) | 2016.07.12 |
[AngularJS] Module (0) | 2016.07.12 |
AngularJS는 정적인 HTML을 확장하여 동적인 응용프로그램으로써의 웹을 구현할 수 있도록 도와주는 자바스크립트 프레임워크이다.
MVC(MVVM) 아키텍처 기반, 양방향 데이터바인딩, SPA 개발, 모듈화 프로그래밍, 라우팅 시스템 등 단순한 웹 페이지를 응용프로그램으로 승격시키기 위한 다양한 기반 기술을 제공하는데, 이 중 Directive(디렉티브)는 HTML 요소 즉 뷰(View)에 대한 확장기능을 제공하는 AngularJS의 중요한 기능 중 하나다.
Directive를 사용하면, 자신의 응용프로그램에 최적화된 뷰와 기능을 캡슐화하여 재사용 가능한 컴포넌트를 만들 수 있다. 즉 Directive를 통해 HTML 태그 및 특성을 입맛에 맞게 재정의 가능하며 이를 통해 '사용자 정의 뷰'를 제작 및 필요에 의해 재사용할 수 있게 된다.
* AngularJS 내장 디렉티브
- AngularJS 내부적으로 HTML 확장을 위해 많은 디렉티비를 정의하고 있다. AngularJS 적용을 위해 HTML Element에 추가로 부여했던 특성들, na-app, ng-init, ng-model 등이 대표적 내장 디렉티브이다.
내장 디렉티비의 목록은 다음 url에서 확인 가능핟.
- http://www.w3schools.com/angular/angular_ref_directives.asp
* 사용자 정의 디렉티브
- AngularJS 디렉티브를 사용해서 HTML을 확장시킬 수 있다고 했는데, 먼저 간단한 예제부터 살펴보자
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module("myApp", []);
app.directive("userdirective", function() {
return {
template : "<h1>사용자 정의 디렉티브</h1>"
};
});
</script>
<body ng-app="myApp">
<userdirective></userdirective>
</body>
</html>
가장 기본적인 형태로 구현된 코드형태이지만, 너무나도 간단하다.
디렉티브 역시, AngularJS의 Module에 추가하는 형태로 구현되며, 사용자 구미에 맞는 새로운 HTML Element를 정의하고 페이지에서 새로운 요소를 사용하고 있다.
기존에 정해진 HTML 요소 외에, 사용자가 원하는 이름을 새롭게 정의하고 사용할 수 있다는 측면에서 AngualrJS가 HTML을 '도메인 특화 언어(domain-specific language)'로써의 기능을 부여했다고 할 수 있다.
* 디렉티브 Naming
- 여기서 한가지 주의할 점이 있는데, 디렉티브 이름을 카멜표기법(단어와 단어사이의 첫 글자를 대문자료 표기)으로 지정했을 땐, 각 단어연결문자로 '-'를 사용해야 한다는 것이다. 즉 다음과 같이 user와 Directive사이에 '-' 문자로 분리해야 한다.
...
<user-Directive></user-Directive>
* 디렉티브 구현 문법
- 앞서 예제에서는 가장 단순한 형태의 디렉티브 사용법을 보여준 것이다. 디렉티브는 다음과 같이 세 가지 구성요소를 기반으로 동작한다.
1) 디렉티브 정의 객체(DDO, Directive Definition Object)
- 디렉티브 구현을 위한 필수요소로, 디렉티브의 HTML 템플릿, scope, 컴파일 주기 등을 설정한 객체를 정의한다. 앞서 예제에서도 리터럴 객체를 리턴하고 있는데, 이것이 바로 DDO이다.
2) 컨트롤러
- AngularJS의 컨트롤러와 동일한 방식으로 동작한다. 디렉티브를 위한 상태와 기능을 정의하고 외부와의 각종 상호작용을 구현한다. DDO와는 달리 반드시 컨트롤러를 정의해야 하는 것은 아니지만, 제대로 된 실무용 디렉티브에서는 필수로 구현해야 할 것이다.
3) 링크
- 디렉티브에서 정의한 DOM을 조작하는 코드를 구현한다. DOM 요소에 발생하는 이벤트를 가로채서 각종 처리를 수행한다. DDO와는 달리 선택요소로 반드시 구현하지 않아도 된다.
이와 같은 구성요소들이 포함된 디렉티브 정의를 위한 뼈대를 살펴보자.
//디렉티브 생성
//필요한 경우, 생성자 함수에 서비스를 주입해서 사용
//ex: function($rootScope, myService, ..., ) .. 이후 컨트롤러에서 사용가능
app.directive("userdirective", function() {
var linker = function(scope, element, attrs){
//DOM 조작에 관한 코드를 구현한다
//scope: 현재 작업중인 디렉티브에 할당된 scope객체.
//컨트롤러함수의 $scope와 동일. 이를 통해 여기서 컨트롤러 함수 호출 가능
//element: 디렉티브가 선언된 요소에 대한 참조를 jQuery 객체로 감싸서 제공
//attr: 디렉티브가 선언된 요소에 정의된 모든 특성을 배열로 제공
};
var controller = function($scope){
//디렉티브의 뷰에서 사용할 비즈니스 로직(상태와 메서드) 구현
//링크함수와 동일한 scope객체 공유
};
return { //DDO객체
restrict: 'A', //이 디렉티브를 HTML요소의 특성(attribute)으로만 사용하도록 제한
controller: controller, //디렉티브의 컨트롤러함수 지정
controllerAs: 'userdirective' //userdirective라는 이름으로 controller 참조
link: linker //링크함수 지정
//이 디렉티브가 HTML Element로 사용될 경우 다음과 같이 템플릿 지정
//template : "<h1>사용자 정의 디렉티브</h1>" //뷰를 위한 HTML 템플릿 지정
};
});
DDO(디렉티브정의객체)에 보면 restrict 속성이 있는데 이것은 해당 디렉티브를 HTML에서 사용할 때 특정 용도로 제한하기 위해 사용한다. 코드예제에서는 'A'라고 지정했는데 이는 HTML요소의 특성(Attribute)로만 이 디렉티브를 사용하도록 제한한 것이다. 다음은 restrict로 지정가능한 옵션이다.
그리고 template로 HTML을 직접 작성했는데, 외부에 이미 존재하는 html 파일을 지정할 수도 있다. * 사용자 정의 디렉티브 샘플
이때는 template 대신 templateUrl: 'directive.html' 형태로 사용한다.
- 이제 디렉티브의 구성요소를 대부분 사용해서 만들어보자
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module("myApp", []);
app.directive("mybutton", function(){
var linker = function(scope, element, attrs){
//마우스 over/out 이벤트에 반응하여 투명도를 조절한다
element.bind('mouseover', function(e) {
element.css({'opacity': 0.5});
});
element.bind('mouseout', function(e) {
element.css({'opacity': 1.0});
});
};
var controller = function($scope){
var ctrlMyBtn = this;
ctrlMyBtn.text = "My Button";
ctrlMyBtn.getText = function(){
alert(ctrlMyBtn.text);
}
};
return {
restrict: 'A',
controller: controller,
controllerAs: 'ctrlMyBtn',
link: linker
};
});
</script>
<body ng-app="myApp">
<button mybutton ng-click="ctrlMyBtn.getText();">
{{ctrlMyBtn.text}}
</button>
</body>
</html>
- 예제코드가 그다시 쓸모있는 디렉티브라고는 할 수 없지만, 디렉티브의 구성요소가 어떤식으로 상호작용하여 동작 하는지 파악하기에는 더없이 좋을 것이다.
HTML Element의 특성으로만 사용가능한 디렉터리를 만들고 마우스 오버/아웃에 따른 DOM 투명도 조작과 컨트롤러에 정의된 속성과 메서드와 상호작용하는 예를 보여준다.
결과화면은 다음과 같다.
* 참고자료
- https://docs.angularjs.org/guide/directive
- http://www.w3schools.com/angular/angular_directives.asp
'모바일 > Javascript' 카테고리의 다른 글
[Node.js] socket.io를 활용한 웹채팅 구현 (5) | 2016.07.15 |
---|---|
[AngularJS] Route (0) | 2016.07.14 |
[AngularJS] $scope과 controller-as 문법 (0) | 2016.07.12 |
[AngularJS] Module (0) | 2016.07.12 |
[AngularJS] Two-way Data Binding (0) | 2016.07.10 |
* Scope 객체
AngularJS의 $scope은 뷰(View)와 컨트롤러(Controller)를 연결하는 객체이다.
HTML 페이지(뷰)는 자기자신이 포함된 컨텍스트의 $scope객체를 통해 컨트롤러에서 관리하는 데이터와의 양방향 동기화가 가능하며 컨트롤러가 제공하는 메서드도 호출할 수 있게 된다.
- 출처: https://github.com/Capgemini/ngTraining/wiki/AngularJS-Templates-101
그림에서 보는것과 같이, Scope은 비지니스 로직과 사용자 인터페이스간 연결을 담당하며 Controller는 Scope에 속성과 메서드를 추가하여 뷰에 노출시킨다.
scope 객체를 통해 컨트롤러와 뷰가 상호작용하는 간단한 코드를 보자.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module('myApp', []);
app.controller('myCtrl', function($scope) {
$scope.name = "Park";
$scope.changeName = function(){
$scope.name = "Kim";
}
});
</script>
<body>
<div ng-app="myApp" ng-controller="myCtrl">
<h1 ng-click="changeName();">{{name}}</h1>
</div>
</body>
</html>
컨트롤러에서 $scope객체에 name속성을 추가하고 값을 할당하였다. 또한 changeName이라는 메서드를 추가하고 name값을 변경하는 코드를 작성했다.
그리고 HTML 페이지에서는 {{name}} 표현식을 사용하여 scope에 정의된 name값을 출력하고 값이 클릭되면 changeName() 함수를 호출하도록 하였다.
이렇듯 컨트롤러에서 $scope 객체를 통해 속성과 함수를 노출하면 뷰에서는 이와 상호작용 할 수 있게 되는 것이다.
* controller-as 문법
AngularJS 1.3부터 추가된 것으로, 뷰에서 컨트롤러를 선언하는 방식에 대한 문법이다.
기존까지는 ng-controller="controllerName" 이라고 선언하는 반면, 이 문법을 사용하면
ng-controller="controllerName as ctlName"과 같이 선언하는 방식이다. as 뒤에 오는 것은 일종의 별칭으로 뷰에서 ctlName이라는 키워드를 통해 컨트롤러에 접근할 수 있게 되는 것이다.
다음 코드는 앞선 예제에서 $scope 객체를 사용하는 대신, controller-as 문법으로 교체한 것이다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module('myApp', []);
app.controller('myCtrl', function() {
var main = this;
main.name = "Park";
main.changeName = function(){
main.name = "Kim";
}
});
</script>
<body>
<div ng-app="myApp" ng-controller="myCtrl as main">
<h1 ng-click="main.changeName();">{{main.name}}</h1>
</div>
</body>
</html>
controller-as 문법의 사용으로 더 이상 컨트롤러 생성자 함수로 $scope 객체를 주입하지 않아도 된다. 그리고 HTML페이지(뷰)에서는 main이라는 이름으로 컨트롤러에 접근할 수 있게 되었다.
내부적으로는 controller-as 문법으로 정의한 컨트롤러의 이름은 여전히 $scope 객체 내부에 해당 일므의 변수로 추가된다.
그리고 참고로, 컨트롤러 코드에서 var main = this 하고 한 것은 필수 사항은 아니다. 단지 자바스크립트이 함수 컨텍스트 상의 this의 의미 모호성을 제거하기 위해 main이라는 임의의 이름으로 this(자기자신)를 미리 할당한 것이다. 이때 이왕이면 뷰에서 사용하는 이름과 똑 같이 하면 가독성이 좋아질 것이다.
사실 AngularJS 팀이 $scope 대신 controller-as 문법을 사용하기를 권장하고 이 문법을 추가한 것은 두 가지 이유 때문이다.
1. 뷰가 참조하는 컨트롤러의 모호성 제거
- $scope 객체를 통해 추가시킨 속성이나 메서드를 뷰에서 접근할 경우, 단지 속성명(메서드명)만 명시하면 된다. 이는 여러 컨트롤러가 복합적으로 사용되는 환경일 경우, 마크업에서 바인딩에 사용한 속성이 정확히 어디에 정의된 것인지에 대한 모호함을 유발시키며 이는 곧 코드의 가독성 및 유지보수성을 저해시킨다.
2. 묵시적 scope 상속의 나쁜 습관 방어
- 모든 scope 객체는 자신의 직계부모로부터 $rootScope에 이르기까지 계층 구조상 모든 부모 객체의 프로토타입을 상속받는다. 뷰에서 scope의 속성이나 메서를 참조할 경우 자신이 속한 컨텍스트의scope에 해당 속성(메서드)가 존재하지 않을 경우, scope 프로토타입 체인을 거슬러 올라가며 부모 객체를 계속 탐색해 나간다. 이런 동작은 프로토타입 기반의 상속 매커니즘을 가진 자바스크립트의 매커니즘과도 일치하며, 어떤 경우에는 편한 기능이기도 하다. 다만 게으른 개발자라면 부모 scope에 존재하는 속성이나 메서드를 그대로 사용하려고 할 것이며, 여러 곳에서 응용프로그램 전체에 걸쳐 공유되는 데이터에 접근하여 마구잡이로 변경하면 예측하지 못하는 문제들이 발생한다.
controller-as 문법은 더 나은 코딩을 위한 권고사항일 뿐이다. 우리는 여전히 $scope를 사용할 수 있다.
* Scope Hierarchies(Scope의
- 모든 AngularJS 응용프로그램은 하나의 root scope를 가지며, 이 root scope를 기준으로 컨트롤러나 디렉티브 내의 scope가 DOM 구조의 계층구조와 유사하게 child scope로 계층화 된다.
(단, DOM 계층구조가 모든 scope 계층구조를 결정하는 것은 아님에 주의하자)
즉 하나의 root scope와 하나 이상의 chind scope 형태의 계층구조로 이뤄지며, 이런 구조는 뷰가 scope 객체를 참조할 경우 자동으로 scope 프로토타입 체인을 거슬러 올라가며 탐색하도록 동작한다.
다음의 코드는 Scope의 계층구조 구성을 보여주며, 하위 계층에서는 상위계층의 속성에 접근할 수 있다는 것을 보여주고 있다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module('myApp', [])
app.controller('ctrl_A', function($scope, $rootScope) {
$scope.name = 'name-A';
$scope.nameA= 'name-A-only';
$rootScope.masterName = 'master';
});
app.controller('ctrl_B', function($scope) {
$scope.name = 'name-B'
$scope.nameB = 'name-B-only'
});
</script>
<body>
<div ng-app="myApp">
<div ng-controller="ctrl_A">
<h1>Controller A</h1>
{{name}}, {{nameA}} , {{nameB}} {{masterName}}
<div ng-controller="ctrl_B">
<h1>Controller B</h1>
{{name}}, {{nameA}} , {{nameB}}, {{masterName}}
</div>
</div>
</div>
</body>
</html>
결과는 다음과 같다.
B컨트롤러는 A컨트롤러 하위계층에 속하며, B컨트롤러에 정의되지 않은 nameA속성과 rootScope의 masterName 속성에 접근할 수 있다. 반면 A컨트롤러는 B컨트롤러에 정의된 nameB 속성에 접근하지 못한다. 이로써, scope는 계층구조로 구성되며(묵시적으로 상속된다) 하위 scope는 자신에게 정의되지 않은 속성(메서드)를 찾기 위해 상위계층으로 거슬러 올라가며 자동으로 탐색한다는 것을 알 수 있다.
이번엔, 앞의 코드를 controller-as 문법을 사용하여 수정해 보자
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module('myApp', [])
app.controller('ctrl_A', function($rootScope) {
var ctrlA = this;
ctrlA.name = 'name-A';
ctrlA.nameA= 'name-A-only';
$rootScope.masterName = 'master';
});
app.controller('ctrl_B', function() {
var ctrlB = this;
ctrlB.name = 'name-B'
ctrlB.nameB = 'name-B-only'
});
</script>
<body>
<div ng-app="myApp">
<div ng-controller="ctrl_A as ctrlA">
<h1>Controller A</h1>
{{ctrlA.name}}, {{ctrlA.nameA}} , {{ctrlB.nameB}}, {{masterName}}
<div ng-controller="ctrl_B as ctrlB">
<h1>Controller B</h1>
{{ctrlB.name}}, {{ctrlA.nameA}} , {{ctrlB.nameB}}, {{masterName}}
</div>
</div>
</div>
</body>
</html>
코드의 결과는 앞의 $scope 객체를 사용한 것과 동일하다. 하지만 뷰에서 참조하는 속성(메서드)이 정확히 어떤 컨트롤러에 정의된 것인지는 더욱 분명해 졌다.
* 다이제스트 주기(Digest cycle)
- AngularJS는 모델과 뷰의 내용을 자동으로 동기화 시킨다. 그 중심에 scope가 있다. scope는 MVVM 아키텍처 패턴에서 ViewModel에 해당하는 핵심 객체로 이해해도 무방하다.
AngularJS는 scope에 저장된 값이 변경되면 자동으로 뷰도 갱신시킨다. 이것은 AngularJS를 강력하게 만든 양방향 동기화이다. 그런데 이와같은 자동 동기화는 어떤 메커니즘으로 구현될 것일까?
AngularJS는 다이제스트 주기라는 순환적 매커니즘 하에 모델과 뷰를 자동으로 동기화 시킨다.
이 동작은 더티체크(dirty check)라는 개념 위에 구현된 것이며, 이것은 단순히 angular.equals 메서드를 이용하여 속성값이 이전 값과 현재 값을 비교하여 동기화 여부를 결정하는 것이다.
다음 그림은 AngularJS 공식 사이트에 게제된 다이제스트 주기를 표현한 그림이다.
아래 설명은 AngularJS in action의 설명을 요약(조금 수정)한 것이다.
AngularJS는 컴파일 과정을 거치면서 $scope 객체에 정의된 모든 속성에 대한 감시(watch) 표현식을 생성한다. 감시 표현식을 통해 $scope객체의 속성이 변경된 것을 알게 되면 리스너 함수가 호출된다.
간혹 AngularJS가 속성값이 변경되었다는 사실을 알아내지 못하는 경우도 있다. 이런 경우 $apply 객체를 통해 다이제스트 주기를 직접 실행할 수 있다. 대부분 API 호출이나 서드 파트 라이브러리가 수행한 작업을 AngualrJS에게 알리고자 할 때 이 기법을 활용한다.
AngularJS의 자동 바인딩 메커니즘의 개략적인 설명이며, 보다 자세한 이해를 위해서 다음의 블로그에 정리된 글을 읽어 보기를 권장한다.
=> http://www.nextree.co.kr/p8890/
설명이 아주 쉽고 자세히 잘 되어 있으며, 특히 실무에서 자주 맞주칠 수 있는 3rd Party 라이브러리 사용시 자동 바인딩을 위한 $scope.$apply() 함수 사용부분을 빼먹지 않고 봐두기를 바란다.
AngularJS는 기본적으로 위에서 설명한 메커니즘 하에, scope 속성이 변경되면 뷰에 자동으로 변경을 반영시킨다. 하지만 AngularJS의 관리 밖의 영역에서 발생한 이벤트는 인식하지 못하기 때문에 scope 속성값의 변화를 감지하지 못하게 된다. 따라서 $scope.$apply() 함수를 이용해 수동으로 다이제스트 주기를 시작하도록 할 수 있다.
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] Route (0) | 2016.07.14 |
---|---|
[AngularJS] Directive (0) | 2016.07.13 |
[AngularJS] Module (0) | 2016.07.12 |
[AngularJS] Two-way Data Binding (0) | 2016.07.10 |
[AngularJS] MVC Pattern in Angular (0) | 2016.07.10 |
AngularJS의 Module(모듈)은 평범한 HTML 페이지를 AngularJS 응용프로그램으로 확장시키기 위한 진입점이다. AngularJS는 Module을 통해 controller, service, filter, directive 등을 추가하는 방식으로 동작한다.
또한 전역네임스페이스를 오염시키지 않는 전형적인 모듈패턴을 지향하며 나아가 모듈화 프로그래밍을 가능케 하는 아키텍처링 방법으로 설계되었다.
AngularJS 모듈을 그 역할 관점에서 다음과 같이 다양하게 정의해 볼 수 있을 것이다.
- HTML 페이지를 AngularJS 응용프로그램으로 확장시키기 위한 진입점
- HTML 페이지와 AngularJS가 상호작용하기 위한 매개체
- 연관된 각종 컴포넌트를 포함하는 컨테이너
- AngularJS 응용프로그램의 구성을 논리적으로 조직화하는 단위
- 모듈화 프로그래밍을 지원하는 AngularJS의 아키텍처 지원 기능
* Module 생성과 로딩
- 모듈 생성과 로딩은 모두 angular.module 함수를 통해 이뤄진다. 첫 번째 매개변수는 모듈 이름을 지정하며 두 번째 매개변수는 해당 모듈과 연관된 서브모듈을 배열으로 지정할 수 있다.
서비모듈 지정은 모듈을 생성할 때만 지정 가능하다.
angular.module("myApp", []);
//생성한 모듈 가져오기
var app = angular.module("myApp");
* HTML페이지를 AngularJS 앱으로 확장시키기
- 이렇게 생성한 모듈을 HTML 페이지의 특정 Element에 지정하면 그 Element하위 요소들은 AngularJS 응용프로그램으로 동작가능하게 된다. 이때 ng-app 지시자를 통해 해당 앱이 사용할 모듈이름을 지정한다. (참고로 한 페이지에 모듈은 하나만 지정이 가능한데 만일, 두 개 이상의 서로다른 모듈을 지정한 경우 HTML 페이지 기준으로 가장 상단에 지정된 모듈만이 정상 동작할 것이다.)
var app = angular.module("myApp", []);
</script>
* 모듈에 컴포넌트 추가하기
- 모듈은 연관된 각종 컴포넌트를 포함하는 컨테이너 역할을 하며, 이렇게 필요에 의해 추가된 컴포넌트들을 이용하여 HTML페이지를 동적인 MVC 어플리케이션으로 동작시킬 수 있다.
다음 그림은 모듈을 통해 구성가능한 컴포넌트를 보여준다
(출처: http://www.c-sharpcorner.com/article/module-and-controller-in-angularjs/)
실제로 AngularJS 학습의 대부분은 그림에서 보는 것과 같은 컴포넌트의 사용법을 익히는 것이다. 각 컴포넌트의 상세한 설명은 개별 주제를 다룰 때 보기로 하고 여기서는 대략 다음과 같은 코드로 모듈에 필요한 컴포넌트를 추가할 수 있다는 것만 알고 넘어가자
app.controller("MyCtrl", function() { } ); //모듈에 컨트롤러 정의
app.service("MySvc", function() { } ); //모듈에 서비스 정의
app.directive("MyDir", function() { } ); //모듈에 디렉티브 정의
패턴은 거의 동일하다. 각 컴포넌트에 해당하는 메서드를 호출하고 컴포넌트의 이름과 익명함수를 전달하는 방식으로 동작한다. 모듈 메서드는 다음 그림을 참고하기 바란다.
- AngularJS의 모듈 로딩은 설정단계와 실행단계라는 두 단계를 거치며 각 단계를 위한 코딩블럭이 제공된다.
(설정블럭, Configuration blocks)
- 모듈 로딩의 첫 단계로, 모든 프로바이더를 연결하고 등록한다. 오직 프로바이더와 상수만이 설정블록에 주입될 수 있다.
(실행블럭, Run blocks)
- Injector가 생성된 후에 실행되며, 응용프로그램을 시동하는데 사용된다. 이 시점 이후에 추가적인 시스템 설정이 이뤄지는 것을 방지하기 위해, 실행블록에는 오직 인스턴스와 상수만을 주입할 수 있다.
AngularJS는 응용프로그램을 실행할 때, 해당 모듈의 설정영역을 먼저 실행한 후 실행영역을 실행시킨다. 실행영역은 일종의 main 메소드 같은 역할로 모든 서비스가 설정되고 인젝터가 생성된 후에 실행된다.
설정블럭과 실행블럭에 대한 자세한 내용은 다음 블로그를 참고하기 바란다.
- AngularJS의 설정단계(configuration phase)와 실행단계(run phase)
* 모듈화 프로그래밍(서브 모듈 사용하기)
- AngularJS의 Module은 응용프로그램의 구성을 논리적으로 조직화하는 단위로써도 역할을 한다. 아마 이것이 AngularJS Module의 핵심가치일 것이다.
이로써 모듈화 프로그래밍이 가능해 지는 것인데, 모듈화를 하면 연관된 것끼리는 묶고 서로 다른 것끼리는 분리해서 조직화 가능하며 필요한 모듈을 그때그때 조합해서 하나의 전체 응용프로그램을 완성시킬 수 있다. 이 역시 '관심사의 분리'라는 대원칙이 적용된 SW설계 기법이며 모듈화가 잘 이뤄진 프로그램은 재사용성/생산성/유지보수성이 향상되고 테스트용이성도 높아진다.
(공학적으로 모듈화가 잘 되었다는 것은 '응집도'는 높고 하게 '결합도'는 낮게 구성하는 것이다)
모듈화의 가치는 응용프로그램의 규모에 따라 달라진다.
아주 작고 간단한 프로그램 환경에서는 모듈화가 복잡성만 증가시키는 별 필요없는 기법이 된다.
하지만 프로그램의 크기가 상당하고 여러명의 개발자가 참여하는 개발환경이라면 모듈화는 거의 필수적인 기법이라 할 수 있다.
간단한 시나리오를 가정해 보면, ToDo 리스트를 관리하는 앱을 개발할 경우 다음과 같이 조직화 가능할 것이다.
- 메인모듈, 공용모듈, 사용자모듈, 인증모듈, ToDo 아이템 모듈, ....
순전히 개인적인 구분이지만, 프로그램의 성격과 규모에 따라 모듈화의 기준은 달라질 것이다.
다음 코드예제는 AngularJS Module을 이용해 모듈을 역할별로 분리하고 이를 조합하여 구성한 즉 모듈화 프로그램을 작성한 예이다.
먼저 MyApp이라는 메인 모듈을 생성하고 이 모듈이 의존하는 서브모듈(MyApp.User, MyApp.Common)을 배열로 전달한다.
MyApp.User 모듈은 사용자정보를 추상화한 모듈이며, MyApp.Common 모듈은 전체 응용프로그램에 공통적으로 사용될 상수를 정의한 모듈이다. 이 각각의 모듈은 메인모듈의 서브모듈로 등록되어 메인모듈의 컨트롤러의 생성자 함수에 서브모듈의 컴포넌트가 주입되는 방식으로 동작한다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var myApp = angular.module("MyApp", ["MyApp.User", "MyApp.Common"]);
myApp .controller("MainCtrl", function(userlist, APPLICATION_CONFIG){
var main = this;
main.users = userlist.getUsers();
main.appConfig = APPLICATION_CONFIG;
});
var userModule = angular.module("MyApp.User", []);
userModule.service('userlist', function(){
var user = this;
var mock = [
{name: 'Park', city: 'Pusan'},
{name: 'KIM', city: 'Seoul'},
];
user.getUsers = function(){
return mock;
};
})
var commonModule = angular.module("MyApp.Common", []);
commonModule.constant("APPLICATION_CONFIG", {config1: "value1", config2: "value2"});
</script>
<body>
<div ng-app="MyApp" ng-controller="MainCtrl as main">
<h1>Users</h1>
<ul>
<li ng-repeat="user in main.users">
{{user.name + ', ' + user.city}}
</li>
</ul>
<div>{{ main.appConfig.config1 + ", " + main.appConfig.config2 }}</div>
</div>
</body>
</html>
* AngularJS 내장 모듈과 3rd-Party 모듈
- 앞서 모듈화 코드에서 구현한 모듈은 일종의 사용자 정의 모듈이다. 즉 개발자가 필요에 의해 임의로 생성한 모듈이다.
AngularJS는 유용한 기능을 미리 모듈화 시켜두고 이를 사용할 수 있도록 하고 있다. 이것을 AngularJS 내장모듈이라고 하는데 대표적으로 다음과 같은 것들이 있다.
- ngRoute: URL 라우팅 기능 제공
- ngAnimate: 애니메이션 기능 제공
- ngCookies: 웹 쿠키 기능 제공
더 많은 내장 모듈이 있지만, 차차 알아보기로 한다.
또한 인터넷의 제 3자에 의해 유용한 기능들을 모듈화하여 제공하기도 한다. 마치 플러그인 처럼 필요한 모듈을 가져다가 자신의 응용프로그램에 적용할 수 있다.
다음 사이트는 AngularJS 모듈을 검색하거나 새로운 모듈을 등록할 수 있다.
- http://ngmodules.org/
* 참고자료
- https://docs.angularjs.org/guide/module
- http://www.w3schools.com/angular/angular_modules.asp
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] Directive (0) | 2016.07.13 |
---|---|
[AngularJS] $scope과 controller-as 문법 (0) | 2016.07.12 |
[AngularJS] Two-way Data Binding (0) | 2016.07.10 |
[AngularJS] MVC Pattern in Angular (0) | 2016.07.10 |
[AngularJS] 일주일 탐방기 (0) | 2016.07.06 |
처음 AngularJS를 접했을 때 가장 눈에 띄는 특징이 바로 양방향 데이터 바인딩(Two-way Data Binding)이었다.
개인적으로, 자동 바인딩의 참신함은 knockout.js에서 그 놀라움을 처음 발견하였는데, 어느덧 더욱 발전된 형태의 양방향 자동바인딩을 AngularJS에서 어여쁘게 제공하고 있지 않은가...
이는 단연 AngularJS의 가장 큰 장점이며, 이 프레임워크를 채택하는데 있어, 가장 주요한 기준일 것이다.
AngularJS의 양방향 바인딩은, 응용프로그램의 '모델'과 이를 표시하는 '뷰'간의 자동 동기화를 지원하는 기능이다. 조금 다른 측면에서 설명하자만 자바스크립트 영역과 HTML 영역간의 데이터 동기화를 지원하는 것이다.
AngularJS 공식 사이트에서는 다른 전형적인 자바스크립트 템플릿 시스템과 AngularJS의 바인딩을 다음과 같이 그림으로 비교하고 있다.
Data Binding in Classical Template Systems
- 여타 프레임워크는 단방향 바인딩만 지원 |
Data Binding in Angular Templates
- AngularJS는 양방향 바인딩으로 동작 |
가장 보편적으로 사용되는 jQuery의 경우를 보면,
jQuery 탐색 기능을 사용하여 DOM에서 특정 HTML요소를 찾아내어 이벤트를 리스닝하고, DOM요소의 값을 파싱해서 이 값을 가지고 필요한 작업을 수행하고 했다.
AngularJS에서는 단순히 자바스크립트 속성을 정의하고 이것을 HTML에 바인딩만 하면 된다. 그것으로 끝이다.(by AngularJS in Action)
jQuery의 DOM 탐색, 이벤트 리스닝, 수동 동기화 코드로 가능한 바인딩 작업을 AngularJS에서는 극도로 단순화 시킨 것이다.
* 자동 데이터 바인딩
자동 데이터 바인딩을 위한 아주 간단한 코드를 한번 살펴보자
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<body>
<div ng-app="">
<p>Input something in the input box:</p>
<p>Name : <input type="text" ng-model="name" placeholder="Enter name here"></p>
<h1>Hello {{name}} </h1>
</div>
</body>
</html>
모델과 뷰의 동기화를 위해 필요한 작업이 이것이 전부이다.
- ng-app 선언: 해당 영역이 AngularJS 응용프로그램으로 동작하도록 선언한다. 여기서는 모듈의 이름을 생략했는데, 실제 규모있는 앱을 제작하는 경우에는 적절한 이름을 지정하는 것을 권장한다.
- ng-model 지정: 모델로 사용할 값을 지정하는 것으로, 여기서는 input 박스에 name이라는 이름으로 모델을 지정했다. ng-model 디렉티브는 모델로부터 뷰로 데이터를 바인딩 시키기 위해 사용하며 이렇게 하면 AngularJS는 자동으로 $scope 객체의 속성으로 추가되어 뷰와 상호작용이 가능해진다.
- {{ }} 표현식: 모델로 지정한 값을 HTML로 바인딩하기 위한 표현식을 기술한다. 모델값이 변경되면 HTML에 표시된 값이 자동으로 즉각 반영될 것이다.
결과화면은 다음과 같댜. input박스의 값을 변경시키면 그 즉시 HTML에 표시된 값도 같이 변경된다.
* 양방향 (자동) 데이터 바인딩
그럼 이제, 좀더 일반적인 형태의 AngularJS 예제를 보자.
아래 코드는, AngularJS에 컨트롤러를 정의하고 이 컨트롤러를 통해 모델 정보에 접근하도록 했다.
이것이 보편적인 AngularJS 코딩 방법이다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module('myApp', []);
app.controller('myCtrl', function() {
main = this;
main.name= "mkex"; //모델로 사용될 정보. HTML영역에 바인딩되어 자동 동기화 됨
//자바스크립트 영역의 값의 변화를 보기 위한 메서드
main.getName = function(){
return alert(main.name);
}
});
</script>
<body>
<div ng-app="myApp" ng-controller="myCtrl as main">
Name: <input ng-model="main.name">
<h1>{{main.name}}</h1>
<button ng-click='main.getName()'>check</button>
</div>
</body>
</html>
input 박스의 데이터 변화는 HTML에 바인딩 된 값 뿐만 아니라, 자바스크립트 영역에 정의된 컨트롤러의 main.name 속성의 값도 자동으로 반영된다. 이것이 양방향 자동 바인딩 인 것이다.
(데이터 바인딩은 사용자가 속성값을 직접 조작할 수 있는 HTML 폼 같은 특별한 경우에는 양방향으로 동작한다 - by AngularJS in Action)
결과화면은 다음과 같다.
이 얼마나 극강의 생산성을 보여주는 기능인가? 자바스크립트 영역에 정의된 각종 데이터와 이 데이터를 투영하는 HTML요소의 자동 바인딩은 웹 응용프로그램의 무한한 가능성을 쉽게 시도할 수 있도록 할 것이다. 자바스크립트 객체만 잘 관리하면 HTML에 표시되는 것은 신경쓰지 않아도 되며 반대로 HTML로 부터 발생한 변경사항 역시 자바스크립트 객체로 바로 반영될 수 있어 SPA 실현은 쉬운 죽 먹기가 될 수 있다는 것이다. 놀라웁다~
* 단방향 데이터 바인딩(One-way Data Binding)
- 항상 그렇듯이, 훌륭한 기능도 필요치 않을 때가 종종 생긴다. AngularJS의 자동 양방향 데이터 바인딩은 진정 휼륭하지만, 어떤 경우에는 이 기능이 오버스펙일 경우가 있다.
또한 양방향 데이터 바인딩은 내부적으로 변경사항을 감시하는 메커니짐을 내포하고 있어 오버헤드가 생길 수 밖에 없다. (세상에 공짜는 없다)
이에, AngularJS 1.3부터는 one-time binding 이라는 일회성 바인딩 기능을 제공한다.
일회성 바인딩을 적용하기 위해 필요한 것은 단지, '더블클론(::)'의 지정 뿐이다.
이전의 예제에서 단방향 데이터 바인딩으로 변경해 보자.
아래 코드를 보면, 바뀐 것이라곤 고작 두 개의 콜론을 추가한 것 뿐이다. 이로써 최초 한번만 바인딩 되고 이후 변경사항은 HTML로 전파되지 않는다.
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script>
var app = angular.module('myApp', []);
app.controller('myCtrl', function() {
main = this;
main.name= "mkex";
main.getName = function(){
return alert(main.name);
}
});
</script>
<body>
<div ng-app="myApp" ng-controller="myCtrl as main">
Name: <input ng-model="::main.name">
<h1>{{::main.name}}</h1>
<button ng-click='main.getName()'>check</button>
</div>
</body>
</html>
결과를 보면 더욱 명확하다.
최초 mkex라는 자바스크립트 영역의 속성 값이 HTML요소로 동기화 되었으며 이후 input 박스의 변화는 더 이상 HTML요소로 동기화 되지 않는다.
다만 alert 창을 보면 input 박스의 변경은 자바스크립트 속성의 변화만 일으킨다.
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] $scope과 controller-as 문법 (0) | 2016.07.12 |
---|---|
[AngularJS] Module (0) | 2016.07.12 |
[AngularJS] MVC Pattern in Angular (0) | 2016.07.10 |
[AngularJS] 일주일 탐방기 (0) | 2016.07.06 |
knockout.js (0) | 2013.11.14 |
MVC(Model-View-Controller)는 아주 오래된 SW아키텍처패턴이다.
(이 패턴이 소개된 시기는 1979년으로, 길지않은 SW공학분야에서는 고전적인 패턴이라 할 수 있다.)
이 패턴은 백엔드개발자(웹서버 사이드 개발자)에게는 이미 익숙한 패턴일 것이다.
자바의 JSP(스트럿츠), 서블릿, Bean 등의 상호연동 구조가 MVC 모델에 기반하고 있으며, 닷넷은 자사 웹개발플랫폼 기술 이름 자체를 ASP.NET MVC로 하여 MVC 구조를 지향하고 있다.
그러니, 그들(웹서버 사이드 개발자)이 이 패턴에 익숙한 것은 당연한 것이다.
반면, 웹 프론트엔드 개발자에게는 조금 낯설수도 있다.
물론 자바스크립트를 코어하게 학습하거나, ExtJS/Sench Touch와 같은 MVC 모델에 기반한 프레임워크를 다뤄본 적이 있다면, 역시 익숙한 개념일 것이다. (그래.. 중요한 것은 익숙함의 차이인 것이다.)
이 패턴의 핵심은, 모델이 어쩌구.. 뷰가 어쩌구가 아니다. 바로 기저에 깔린 사상이다.
그 사상이 바로 '관심사의 분리(관점의 분리)를 통한 상호 독립성 보장'인 것이다.
웹 프론트개발자 관점에서도 '관심사의 분리'라는 사상 자체는 너무나도 자연스러운 개념일 것이다.
바로 HTML과 CSS 그리고 Javascript의 역할 분리를 빗대어 보면 알 수 있다.
흔히 이 셋의 역할을 'HTML(구조)-CSS(표현)-Javascript(동작)'로 정의한다. 이것이 바로 역할의분리, 다시말해 관심사의 분리이며 이렇게 분리된 구조를 통해 상호 독립적인 개발이 보장되어 생산성과 유지보수성 등이 좋아지게 되는 것이다.
MVC 모델 역시 이와같은 관심사의 분리라는 SW공학적 원리가 적용된 아키텍처 패턴인 것이다.
* MVC 패턴
- 대부분의 응용프로그램은 데이터가 사용되며 이 데이터를 기반으로 사용자 인터페이스를 제공한다. MVC패턴은 데이터를 조작하는 비즈니스 로직과 사용자인터페이스를 서로 분리하여 상호 영향 없도록 하는 것에 초점을 맞춘 패턴이다. 이 둘(데이터와 인터페이스)의 상호연동을 위해 컨트롤러라는 새로운 계층을 두고 있는 것이다.
- Model: 응용프로그램의 핵심 로직과 데이터를 캡슐화 수행
- View: 사용자가 보게 되는 인터페이스의 총칭. 모델의 정보를 표시하는 역할수행
- Controller: 모델과 뷰의 연결을 위한 계층으로 사용자 입력을 받아 중계 수행
MVC 패턴에 대한 이론적 내용은 많은 인터넷 자료에서 쉽게 찾아 볼 수 있으니 여기서는 그만 다루도록 한다. 혹여 MVC라는 용어가 어색한 웹 프론트 개발자들이 반드시 짚고 넘어가야 할 점은, MVC는 관점의 분리라는 공학적 원리가 응용프로그램의 구조와 상호작용 부분에 적용된 모범사례라는 것 뿐이다.
* Server Side MVC? Client Side MVC?
- 웹개발 측면에서 보면, MVC 패턴은 웹 서버 사이드 개발에서의 응용프로그램의 구조 패턴으로 먼저 보편화되었다고 할 수 있다. 즉 JSP나 ASP.NET과 같은 서버 측 응용구조로 채택되어 지금까지도 많이 활용되고 있는 패턴이다.
그러나 오늘날 진보적인 웹 클라이언트 개발에 훌륭한 자바스크립트 라이브러리들이 등장하고 이 들이 추구하는 아키텍처 기반 구조 역시 MVC에 근거하고 있다.
전통적인 서버측 개발에서의 View의 영역은 (최종 랜더링되는) HTML 페이지이다. 즉 Controller와 Model은 서버측에 존재하며 (서버가 사용자에게 반환하는) HTML페이지가 바로 View의 영역이 되는 것이다.
이 말은 웹 클라이언트에 존재하는 웹 클라이언트 자체가 View가 된다는 것인데, 웹 클라이언트 영역에서도 이 부분을 다시 MVC로 나누고 있는 것이다. 뭔가 혼란스럽지 않은가?
웹 응용프로그램이란 것이 결국 서버측과 클라이언트 측이 결합되어 하나의 결과물이 되는 것인데, 각각의 영역에서 MVC 패턴을 따로 다룬다면, 전체의 MVC모습은 어떻게 된다는 말인가?
이것은 어떻게 보면 중요한 문제가 될 수 있다. 분업화된 작업방식(서버개발자/클라이언트 개발자)에서 각기 나름의 MVC 모델을 추구한다면 응용프로그램의 전체 구조는 가히 우스운 꼴이 될 수도 있다.
오히려 이 부분은 웹 프론트앤드 개발자에게는 익숙한 것일지도 모른다. 그것은 웹 응용프로그램의 구현모델의 차이를 이해하면 되는 것이다.
* SPA(Single Page Application)에서의 MVC
- 서버측 MVC, 클라이언 측 MVC라는 말 자체가 조금 억지스럽다. 그것은 응용프로그램의 구현모델상의 차이가 날 수 있는 부분이지, 서버와 클라이언트로 구분되지는 않을 것이다.
AngularJS는 SPA 모델을 위한 자바스크립트 프레임워크이다.
SPA는 전통적인 웹 구조와 상반되는 개념으로, 기존의 웹 페이지는 데이터를 전송하고 서버가 이를 처리한 후 완전히 새로운 페이지를 랜더링하는 구조였다.(이를 '호출 후 새로고침' 방식이라 한다)
그러나 현대의 웹 페이지는 단순히 정적 페이지라는 개념을 넘어 사용자의 이벤트에 반응하고 적절한 상호작용을 제공하며 애니메이션과 네비게이션을 자체적으로 해결하는 응용프로그램의 면모를 보여줄 수 있다. 그리고 원격지 서버와의 통신은 더이상 완전히 새로운 페이지의 '새로고침'이 아니라 단일 페이지에서 필요한 데이터만 비동기로 가져와서 사용자의 작업을 방해하지 않으면서 데이터를 갱신시킨다.
결론적으로 전통적인 새로고침 방식의 웹과 SPA 방식의 웹에서의 MVC의 역할 모델이 조금 상이할 수 있다고 할 수 있다.
다시 말하지만, AngularJS는 SPA 실현을 가능케 하는 자바스크립트 프레임워크이다.
SPA모델에서는 대부분의 작업이 클라이언트 측에서 이루어진다. 그리고 서버측 데이터 연동은 Ajax와 같은 통신 모델을 이용하여 비동기로 그때그때 필요한 데이터만 가져와서 사용자 화면을 갱신시킨다. 이런 모델에서의 MVC패턴의 각 영역은 다음과 같다.
- Model: View가 사용할 데이터 또는 공통되고 주요한 비즈니스 로직을 정의한 영역으로 실제 데이터는 대체로 서버측에 존재하게 된다.
- View: 사용자 화면을 구성하는 HTML 영역
- Controller: 뷰와 모델을 연결해 주는 영역으로 SPA모델에서는 클라이언트 측에 존재하게 된다. 좀 더 면밀히 따져보자면, SPA 모델에서는 Controller의 영역을 ViewModel(뷰모델)로 설계되기도 하며, 이는 SPA뿐만 아니라 전통적인 윈도우 응용프로그램(요청과 응답 구조의 웹구조가 아닌) 환경에서 뷰와 모델간 의존성을 제거하고 뷰의 상태와 뷰에 투영될 데이터의 변화에 따른 자동 바인딩을 가능케 하는 구조로써 이와 같은 모델을 MVC의 변형된 모델로 MVVM 패턴이라고 불리운다.
큰 틀에서 정리하자면, Model은 그 역할이, 응용프로그램 전체에 걸쳐 필요한 데이터와 비즈니스 로직을 제공하게 되는데, SPA 구조에서는 이 부분을 클라이언트 측에 추상화 하여 일종의 공용서비스 형태로 구현하며, 실제 데이터는 서버로부터 비동기 형태로 (백그라운드에서) 받아와서 추상화된 서비스계층에 할당하고 뷰모델이라는 중간계층을 경유해 뷰와 바인딩시키는 구조인 것이다.
결국 SPA 에서의 서버측은 응용프로그램에 필요한 데이터를 비동기로 서비스 해 주는 기능만 존재하면 된다는 말이다.(이부분은 대체로 REST API로 구현된다)
SPA모델에서의 MVC는 기존의 새로고침 모델에서의 MVC와는 그 역할에 따른 컴포넌트의 위치와 통신구조에서 차이점을 보이며, 어떤 형태의 모델로 웹 응용프로그램을 구현하는지에 따라 '모델-뷰-컨트롤러'의 실질적 구현레벨의 모습이 약간 다를 수 있다는 것이다.
하지만 관점의 분리라는 사상과 비즈니스 로직(모델)과 뷰를 분리하는 아키텍처 구조는 SPA이든 새로고침방식이든 다르지 않다는 것은 원론적으로 중요하다.
* AngularJS의 MVC 컴포넌트
- AngularJS에서는 MVC 패턴을 기반으로 응용프로그램 구성을 가능케 한다. 어떤이는 MVVM이라 예기하고 싶겠지만 여기서는 상황을 일반화 시켜서 글을 이어 나가도록 한다. MVVM역시 MVC에서 필요에 의해 일부 변형시킨 패턴이며 이 글에서는 그 차이가 그리 중요하지 않기 때문이다.
(실제로 AngularJS는 자신의 아키텍처 기반을 MVW(Model-View-Whatever)라고 부르며 Whatever란 어떤것이라도 가능하다는 뜻으로, MVC/MVP/MVVM 모두 가능하다는 의미이다. 아키텍처 패턴간 발전과정과 특징 및 구조적 차이는 분명이 존재하며 이 들의 관계는 다른 글에서 다시 언급하도록 한다.)
MVC 아키텍처를 위해 AngualrJS가 제공하는 컴포넌트를 알아보자. 다음은 AngularJS 공식 사이트에서 설명하는 내용이다.
* View — The template (HTML with data bindings) that is rendered into the View.
* Controller — The ngController directive specifies a Controller class; the class contains business logic behind the application to decorate the scope with functions and values
AngularJS가 MVC 구현을 위해 제공하는 것중 핵심은, ngController 디렉티브이며 이를 이용하여 뷰를 위한 컨트롤러 클래스를 생성할 수 있다.
Model은 scope의 프로퍼티라고 설명하고 있다. AngularJS에서 $scope은 뷰와 컨트롤러의 연동을 위해 제공되는 객체이며 컨트롤러 객체에서 뷰로 데이터를 노출하기 위한 일반적인 방법을 제공한다.
scope이 모델이다라고 애매한 해석을 하기 보다는, 컨트롤러에서 모델 정보를 뷰로 연결하기 위해 제공되는 객체로 이해하면 될 것이다.
실제 예제를 한번 보자.
<div ng-app ng-init="qty=1;cost=2">
<b>Invoice:</b>
<div>
Quantity: <input type="number" min="0" ng-model="qty">
</div>
<div>
Costs: <input type="number" min="0" ng-model="cost">
</div>
<div>
<b>Total:</b> {{qty * cost | currency}}
</div>
</div>
코드는 뷰와 모델간 가장 기본적인 상호작용을 설명하기 위해 작성되었으며, 데이터에 해당하는 Model정의를 위해 ng-model 디렉티브를 사용했다. ng-model 디렉티브가 지정된 입력박스의 값은 자동으로 $scope객체의 프로퍼티로 정의되며, 더블중괄호로 표현되는 '{{ property of scope }}' 표현식을 통해 모델의 정보를 View로 연결키실 수 있다.
다음 이에 대한 설명으로 AngularJS 공식 사이트에서 제공하는 그림이다.
이제 컨트롤러를 등장시켜 보자.
angular.module('myModule', [])
.controller('InvoiceController', function() {
this.qty = 1;
this.cost = 2;
this.total = function total(outCurr) {
return this.qty * cost;
};
this.pay = function pay() {
window.alert("Thanks!");
};
});
<div ng-app="myModule" ng-controller="InvoiceController as invoice">
<b>Invoice:</b>
<div>
Quantity: <input type="number" min="0" ng-model="invoice.qty" required >
</div>
<div>
Costs: <input type="number" min="0" ng-model="invoice.cost" required >
</div>
<div>
<b>Total:</b>
<span>{{invoice.total}}</span>
<button class="btn" ng-click="invoice.pay()">Pay</button>
</div>
</div>
컨트롤러는 뷰가 바인딩하고 다룰 수 있는 속성과 메서드를 정의하기 위한 객체로써 AngularJS 모듈에 연결한다. 코드를 보면 $scope 객체를 찾아볼 수 없는데 이는 controller-as 문법을 사용하여 $scope객체를 명시적으로 사용하지 않아도 되기 때문이다. 중요한 것은 View와 Scope 그리고 Controller의 상호작요이며 다음 그림에 도식화하여 설명하고 있다.
* 일반적인 MVC 패턴 구현
- 이제 AngularJS에서 일반적 MVC 패턴 구현의 전체 모습을 살펴보자. Model의 경우 원격지 서버에 존재하는 데이터를 기반으로 하는게 일반적이며 이와같은 공통적인 데이터를 AngularJS 어플리케이션 전체에 공유하기 위해서는 AngularJS의 Service(서비스) 객체로 생성하는 것이 좋다.
사실 이전까지의 글보다 다음의 코드를 이해하고 이 코드를 기반으로 AngularJS MVC 패턴 구현을 이해하는 것이 보다 현실적이다.
먼저index.html을 다음과 같이 작성한다
<html>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
<script src="app.js"></script>
<body>
<div ng-app="myModule" ng-controller="MainCtrl as main">
<h1>Persons</h1>
<ul>
<li ng-repeat="person in main.persons">
{{person.name + ', ' + person.city}}
</li>
</ul>
</div>
</body>
</html>
AngularJS 관련 자바스크립트 파일을 app.js라는 별도의 파일로 분리했다.
그리고 AngularJS의 모듈과 컨트롤러를 매핑시킨다. 이때 $scope객체를 사용하는 대신, controller-as 문법을 사용한다. 그리고 배열로 반환되는 persons 정보를 ng-repeat 디렉티브로 순환시켜 <ul>태그의 <li>항목으로 각각 매핑시킨다.
그리고 다음은 app.js 파일의 코드이다.
var app = angular.module('myModule', []);
//컨트롤러 생성(컨트롤러 생성자에 PersonModel서비스 전달=>의존성주입(생성자 주입)패턴)
app.controller('MainCtrl', function(PersonModel){
var main = this;
//Personmodel서비스에 정의된 getPersons()함수를 호출
main.persons = PersonModel.getPersons();
});
//서비스 생성
//서비스는 전체 어플리케이션에서 사용하게 될 데이터나 공통 기능을 작성하기 좋은 곳이다
//보통 MVC의 Model 정보를 원격지에서 불러오는 역할을 하도록 한다.
app.service('PersonModel', function(){
var service = this;
//실제환경에서는 persons 정보는 원격지 서버로 부터 받아오는 것이 일반적이지만,
//여기서는 코드의 단순화를 위해 직넙 객체 리터럴로 생성한다.
var persons = [
{name: 'Park', city: 'Pusan'},
{name: 'KIM', city: 'Seoul'},
{name: 'Jung', city: 'suwon'}
];
service.getPersons = function(){
return persons;
};
service.setPersons = function(){
//서버로 부터 받아서 업데이트
};
});
Model 정보를 제공하는 서비스 객체(PersonModel)를 생성하여 컨트롤러 생성자 함수에 주입시킨다. 이렇게 함으로써 Controller와 Model을 물리적으로 분리가능하며 의존성 주입패턴으로 이 둘을 의존성을 관리한다. 컨트롤러는 이제 PersonModel의 속성과 메서드를 사용할 수 있게 되었다.
참고로 서비스와 컨트롤러에서 this키워드를 변수에 저장시키는 것은, 자바스크립트의 동적언어 특징에서 기인하는 문맥(Context)상 this의 해석이 모호해 지는 점을 예방하기 위해 명시적으로 할당해 두는 것이다. 이는 예외적인 동작에 대한 예방차원에서 필요한 코드로 자바스크립트 특징에 기반한 코드사례이다.
결과 화면은 다음과 같다.
지금까지 AngularJS의 MVC 패턴 구현에 대해 장황하게(?) 알아보았다.
대부분의 AngularJS 응용프로그램의 코드 구조는 여기에 살을 더 붙여 나가는 식으로 작성하면 된다. MVC 패턴에 기반한 응용프로그램 구조는 영역간 분리를 통해 상호 독립적 개발과 유지, 단위테스트를 가능케 하여 전체적인 생산성과 유지보수성을 향상시킨다.
중요한 것은 MVC의 사상을 이해하고 AngularJS가 MVC를 위해 제공하는 컴포넌트를 적절히 조합하여 응용프로그램을 구성하는 것이다.
이 글을 바탕으로 좀더 세말한 치장을 해 나가면 될 것이다.
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] Module (0) | 2016.07.12 |
---|---|
[AngularJS] Two-way Data Binding (0) | 2016.07.10 |
[AngularJS] 일주일 탐방기 (0) | 2016.07.06 |
knockout.js (0) | 2013.11.14 |
OOP in Javascript (0) | 2013.08.16 |
오랜만에, 웹 클라이언트 기술에 다시 불을 지펴보고 싶어졌다.
일주일 전, AngularJS를 본격적으로 알아보고자 책 한권 구입해서 대략 전체를 한번 훑어봤다.
기술사 공부할때, Node.JS와 함께 기출 예상되었던 핫(hot)한 자바스크립트 프레임워크 중 하나여서 대략 느낌(?) 정도만 알고 있었는데, 알면 알 수록 매력 떵어리가 아닌가...
특히 CRUD기반의 SPA(Single Page Application) 개발을 위한 최고의 생산성을 보장하는 아주 훌륭한 물건이라 하겠다.
더불어 이젠 전통에 가까워진 MVC(Model View Controller) 아키텍처 사상에 기반을 둔 프로그램 구조를 채택하고 있어 분할과 정복/관심사의 분리라는 소프트웨어 기본 원리가 적용되어 구현의 독립성, 단위테스트의 용이성, 느슨한 결합으로 연결된 전체적인 아키텍처는 유지보수성을 향상시켜 엔트프라이즈급 웹 응용개발에 아주 적합해 보인다.
참고로 AngularJS는 MVW(Model View Whatever)라는 용어로 MVC를 넘어 MVP, MVVM. 뭐든지 다... 라는 발찍한(?) 도발마저 하고 있다.
View와 Model간의 관계성과 중간 연결계층인 Controller의 View와의 차수성이 이들 아키텍처를 나누는 주요 기준이 되는데, 이 부분은 좀 더 면밀히 따져 봐야 할 것 같다.
AngularJS는 아주 유명한 크로스브라우저 라이브러리인 jQuery와 자주 비교되는 사실을 발견했다.
음.. 그 목적과 쓰임새가 분명 다르다는 느낌을 지울 수 없지만, 이 둘이 많은 자료에서 매번 비교되는 것은 jQuery가 이미 산업표준으로 자리매김을 해 버린 웹클라 개발환경에 불현듯(?) 나타나 상승세를 타버린 AngularJS의 유명세와의 시기적 마찰이 그 시발점인 듯 하며 실제로 jQuery로 구현된 많은 부분이 AngularJS로 대체가능 하다는 사실도 한 몫했을 터이다.
앞서, 구매한 책에서는 다음과 같이 이 둘을 언급하고 있다.
수많은 프레임워크들 중에서도 jQuery가 압도적인 지지를 받는다는 점에 대해서는 많은 개발자가 동의할 것이다. jQuery가 수많은 브라우저의 각기 다른 부분을 모조리 추상화하여 개발자들이 브라우저에 관계없이 웹사이트에 단인 API를 사용할 수 있게 해주었다는 사실 때문이다.
그 후로는 애플리케이션과 유사하게 동작하는 웹사이트를 개발할 수 있도록 구현된 프레임워크들이 등장했다. 이들은 완전히 새로운 방식을 도입했다. 예를 들어, jQuery는 DOM을 조작하는 데 필요한 탁월한 도구들을 제공하지만, 애플리케이션 구조에 맞게 코드를 정리하는 것에 대한 실질적인 가이드라인을 제공하지는 않았다. 'jQuery 애플리케이션'을 구현한 코드가 오히려 유지보수가 어렵고 확장성이 떨어지는 괴상한 코드로 변하고 말았다는 안타까운 소식ㅇ르 듣게 되는 것은 바로 이점 때문이다.
이후 유지보수가 쉬운 대규모 자바스크립트 애플리케이션 개발에 대한 수요가 증가하면서 자바스크립트 프레임워크는 전성시대를 맞이한다. 최근 2~3년 사이에는 수많은 프레임워크가 등장하고 또 아무도 모르는 사이에 사려져 갔다. 그러나 몇몇 프레임워크는 유지보수가 쉽고 확장 및 테스트가 수월한 대규모 웹 애플리케이션을 개발하기 위한 필수 옵션으로 자리매김했다. 그중에서도 첫 손가락에 꼽히지는 않지만 매우 대중적으로 알려진 프레임워크가 바로 구글이 개발한 AngualrJS다.
그리고 '웹 엔지니어의 교과서'라는 책에서는 다음과 같이 말하고 있다.
jQuery로 프런트엔드 개발이 매우 편해졌다는 사실을 알았습니다. 그런데 왜 Backbone.js, AngualrJS, Ember.js, Vue.js와 같은 Javascript 프레임워크가 등장한 걸까요? jQuery만으로는 부족했을까요? 그 이유는 크게 두가지로 들 수 있습니다.
1) DOM 변경에 약한 jQuery
- DOM구조에 기반한 탐색으로 인해 DOM 구조변경에 오히려 취약함
- $("$target").parent().next().find(".default").hide();
- 리팩토링이나 수정, 디자인 변경 등으로 DOM구조가 바뀌어 지금까지 next()로 찾았던 형제 요소를 더는 찾지 못하는 상황 등은 충분히 예상할 수 있습니다. 그때마다 짜증을 내면서 jQuery를 수정한 경험이 많을 것으로 생각합니다.
2) 대규모화된 프런트 엔트 개발
- 서버사이드 개발에서 이전부터 MVC라는 디자인패턴을 이요하여 비즈니스 로직은 모델에, 디자인은 뷰에 책임을 분산했습니다. 최근 프런트 엔드 개발 규모가 커지나 서버사이드 개발과 마찬가지로 프런트 엔드 개발에서도 MVC 디자인 패턴으로 비즈니스 로직과 디자인을 따로 분리하려는 경향이 보입니다.
두 책에서 언급한 내용을 요약하자면, 브라우저 호환성을 보장하면서 DOM 조작에 탁월한 능력을 보여주는 jQuery는 DOM 탐색에 기반한 구조가 오히려 유지보수성을 떨어뜨리는 면이 있으며, 보다 큰 차이점은 간단한 웹페이지들의 모음이 아닌 응용프로그램으로써의 규모있는 SPA 환경일 경우 MVC 아키텍처가 가져다 주는 유지보수성과 테스트용이성, 확장성이란 점이다.
물론 AngularJS를 만나면 가장 먼저 눈에 띄는 장점인 '양방향 바인딩'도 jQuery에서는 제공되지 않는 기능이다.
(웹 페이지의 양방향 바인딩은 knockout.js를 첨 접했을 때 깜놀한 기억이 난다. => http://m.mkexdev.net/268)
결론적으로 다시 말하지만, 이 둘은 완전히 서로를 대체한다고 보기는 힘들다는 것이다.
두 프레임워크의 사상과 추구하는 목적이 다르다는 점, 그에 따라 쓰임새 역시 다를 수 밖에 없는것이다. 정말 고무적인 것은 이 둘을 같이 사용할 수 있다는 것이며, AngularJS는 내부적으로 jQuery를 포함하고 있다는 점이다. 이 점은 그야말로 더욱 훌륭하다 하겠다.
* AngularJS의 빠른 학습
앞서 소개한 책은 AngularJS를 실제 SPA 응용프로그램을 작성해 보면서 배울 수 있는 좋은 기회를 제공한다. 또한 AngularJS의 내부동작 등 심도있는 내용도 같이 포진되어 있어 많은 걸 배울 수 있다.
그리고 깊이는 좀 덜하지만 빠르게 테스트 해 볼 수 있는 학습도구로, w3cshools의 다음 강좌를 참조하면 좋다.
http://www.w3schools.com/angular/
마지막으로 AngularJS 자체에서 제공하는 api 문서는 늘 곁에 함께...
'모바일 > Javascript' 카테고리의 다른 글
[AngularJS] Two-way Data Binding (0) | 2016.07.10 |
---|---|
[AngularJS] MVC Pattern in Angular (0) | 2016.07.10 |
knockout.js (0) | 2013.11.14 |
OOP in Javascript (0) | 2013.08.16 |
함수에 대하여 (5) | 2013.07.31 |
임재범과는 또 다른 느낌.
노래 너무 조으다...
'일상' 카테고리의 다른 글
아.. 이러지 맙시다. (0) | 2016.08.25 |
---|---|
평가(특히 면접)에 임하는 자세 (0) | 2016.08.25 |
DIY로...(Ⅱ) (0) | 2014.02.24 |
불혹에 즈음하여... (6) | 2013.12.31 |
정보통신망법 제23조의 2항 위반 (1) | 2013.12.06 |
이런 증상이 있지 않나요? 데브옵스를 처방해 드리겠습니다.
------------------------------------------------------------------------
우찌.. 이런..
이리도 이그젝틀리 한지..
'프로젝트관리' 카테고리의 다른 글
Core/Context 모델 (0) | 2019.03.20 |
---|---|
Tuckman의 팀 발달 모델 (1) | 2019.03.07 |
개발자 칠거지악 (0) | 2015.02.06 |
6하원칙 리더십 (0) | 2014.07.09 |
로그수집에 대한 잡설(전수조사 vs 표본조사) (0) | 2013.09.05 |
초단위로 반복적으로 WCF를 호출하는 응용프로그램이 있다.
이 WCF 응용프로그램의 바인딩은 wsHttpBinding을 설정하였으며 X.509 인증서기반의 Message 보안모드 상태에서 동작한다. 더불어 클라이언트 인증은 UserName 자격증명을 이용중이다.
참고로, WCF는 자체적으로 보안강화를 위해 안전장치를 몇 가지 마련해 두고 있는데, 대표적으로 reply 공격을 방어하기 위해 클라이언트와 서버시간이 일정시간(기본 5분) 이상 차이가 나면 서비스 호출이 불가능하도록 하는 것을 예로 들 수 있다.
이런 안전장치들은 WCF 보안 기능을 사용할 경우, 기본적으로 제공되는 것들이다.
따라서 간혹 보안기능에 문제가 발생할때 이런 기본사항을 인지하지 않고 있다면 문제해결이 어려운 경우가 있다. 물론 이러한 기본 보안장치들은 특정 비즈니스 환경에 적합하지 않을 수도 있기에 개발자에 의해 커스터마이징이 가능하다.
앞서 초단위로 반복 호출되는 WCF 응용프로그램에서, 어느날 다음과 같은 오류가 발견되었다.
이 오류가 초단위로 지속적으로 나타나고 있었다. 메시지 인증을 지속적으로 시도하여 UserName 자격증명을 처리하는 서비스 오퍼레이션이 불필요하게 많이 호출되는 것이다.
메시지 인증을 실행하지 못했습니다. |
이 상황에서의, 클라이언트 측 HTTP 응답오류는 다음과 같다.
HTTP/1.1 500 Internal Server Error <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header> <a:RelatesTo>urn:uuid:2def471f-b90d-498b-85b3-edfcaee8dff1</a:RelatesTo></s:Header> |
WCF Trace Log를 남겨서 조사도해보고, 몇 가지 예상되는 시나리오를 가정하고 테스트를 해 봐도 쉽게 잡히질 않았다. 더욱이 멀티 쓰레드 환경에서 백그라운드로 실행되어, 명시적인 서비스 오퍼레이션 호출에 기인한 메시지 인증의 자동요청이라 패킷검사에서도 서비스 오퍼레이션 이름이 아닌, 인증토큰과 관련된 협상과정만 반복되어 디버깅에 더 애를 먹게 되었다.
유독 특정 사용자에게서만 발생하던 오류라 그 사용자의 PC환경과 응용프로그램 사용패턴을 들여다보고, 자료를 좀 찾아보니 예상되는것이 나온다.
Idle Session 상태에서 보안토큰의 만료시간으로 인한 토큰 검증에 실패한 것으로 추측된다.
그 사용자는 응용프로그램을 실행한 뒤, 한참을 그냥 두고 PC가 유휴상태에 있다가 다시 활성상태로 돌아와서 다시 사용하는 등 Idle Session 상태를 빈번히 유발하는 것이다.
구글링에서 몇 가지 좋은 아이디어를 얻을 수 있었다.
이제 서비스 환경과 정책에 맞도록 idle Session에 대한 보안토큰 만료 완화 혹은 명시적 거부를 구현하기만 하면 될 듯 하다. 이런 오류는 사람을 매우 피곤하게 하지만, 해결이 되면 그마이 기쁜것이 없다.
----------------------------------------------------
http://www.codeproject.com/Articles/156994/WCF-Secure-Channel-cannot-be-opened-Load-Balancing
https://msdn.microsoft.com/ko-kr/library/ms731814(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/ms731346(v=vs.110).aspx
https://msdn.microsoft.com/ko-kr/library/ms731346(v=vs.110).aspx
http://forums.asp.net/t/1760793.aspx?establishSecurityContext+false+
------------------------------------------------------------
해당 오류에 대한 클라이언트 측 Exception 은 최초 키 갱신에 대한 오류 이후, MessageSecurityException 즉, 일반적인 메시지보안 오류가 지속된다.
SessionKeyExpiredException 은 private로, 타입비교가 불가능해, 굳이 해당 예외에 맞춤형 처리를 하고자 한다면 문자열로 변환해서 비교하면 될 듯 하다.
System.ServiceModel.Security.SessionKeyExpiredException: 보안 세션 키를 갱신할 수 없습니다. Server stack trace: |
System.ServiceModel.Security.MessageSecurityException: 상대방으로부터 보호되지 않거나 잘못 보호된 오류를 받았습니다. 오류 코드 및 세부 정보는 내부 FaultException을 참조하십시오. ---> System.ServiceModel.FaultException: 보안 컨텍스트 토큰이 만료되었거나 잘못되었습니다. 메시지가 처리되지 않 았습니다. Server stack trace: InnerException Info>> |
'.NET Framework' 카테고리의 다른 글
미스터 빈, 너로구나 (0) | 2014.07.31 |
---|---|
Caching in WCF (2) | 2014.02.21 |
ASP.NET SignalR (0) | 2013.12.06 |
maxConcurrentSessions in WCF (0) | 2013.11.21 |
SQL Double Split (0) | 2013.11.13 |
IT 전문 매거진에 실린 '개발자가 저지르기 쉬운 7가지 나쁜 습관'의 내용이다.
오늘자 전자신문에 실린 '정보통신산업진흥원 SW공학센터장(이상은)'의 컬럼 내용을 옮겨온다.
자칫 나태해지기 쉬운 개발업무를 돌아볼만 하다.
1. 욕심에 의한 엔지니어링의 남용
- 책에서 제시된 방식들이 항상 효과가 좋은 것은 아니어서 원래 사용했던 방법을 효과적으로 사용하는 것이 더 좋은 방법일 수 있다. 프로그래밍의 대가들은 "새로운 기법을 활용하는 것보다 더 중요한 것은 기능의 효과적 구현이다"라고 말하고 있다.
2. 계속 기능만 추가하고 개발했던 내용을 리팩토링하지 않는 것
- 이미 개발된 코드는 완전하지도 않으며 추가되는 기능이 점점 늘어 갈수록 복잡해지고 뒤엉켜 버리기 때문에 기존 코드의 품질과 유지보수성을 평가해 코드에 대한 신뢰성을 확보하는 것이 중요하다.
3. 개발자 사이의 경쟁
- 팀 간에 프로젝트가 비공개적으로 진행되면 다른 팀이 이미 구현한 라이브러리를 중복적으로 개발하게 된다. 개발의 최우선 과제 중 하나는 각자가 어떤 작업을 하고 있는지 서로에게 알리는 것이고, 모든 팀들이 공통의 목표를 갖고 정보를 공유하는 것이다.
4. 입력값의 유효성 검증에 실패하는 나태함
- 개발하면서 사소한 실수는 빈번히 일어자지만 잘못된 입력값을 받아들이는 개발 실수는 매우 치명적이어서 신중해야 한다.
5. 소스코드에 코멘트를 달지 않는 것
- 일단 개발된 소스코드는 보관되었다가 나중에 유지보수를 위해 다른 사람이 작업을 하게 되는 것이 보통이다. 이때 코멘트가 없다면 해당 코드가 무엇을 의미하는지 이해하기 어렵고 시간도 오래 걸린다. 따라서 최소한 힌트를 남겨둬야 한다.
6. 버전관리를 하지 않는 것
- 요즘엔 강력하고도 효과적인 버전관리 도구를 무료로 손쉽게 구할 수 있다. 심지어 분산 프로젝트를 관리할 정도의 도구도 최소 비용으로 구할 수 있다. 따라서 다른 문제가 없다면 가장 기본이 되는 버전관리시스템은 반드시 만들어둬야 한다.
7. 단위테스트를 하지 않는 것
- 개발된 프로그램이 좋은 평가를 받는 것은 개발자로서 영광스러운 일이다. 하지만 결함을 가진 코드가 출시된다면 그 뒤처리를 감당하기 어렵게 된다. 코드를 출시하기 전에 단위 테스트를 철저히 할수록 나중에 감당해야 하는 피해를 최소화할 수 있다.
'프로젝트관리' 카테고리의 다른 글
Tuckman의 팀 발달 모델 (1) | 2019.03.07 |
---|---|
데브옵스 처방전 (0) | 2015.05.21 |
6하원칙 리더십 (0) | 2014.07.09 |
로그수집에 대한 잡설(전수조사 vs 표본조사) (0) | 2013.09.05 |
공학의 ACE (0) | 2013.06.28 |
netTcpBinding 기반의 WCF 서비스에 다수의 (논리적으로 구분할 수 잇는) 서비스가 구성되어 있다.
서비스는 IIS 호스팅 환경에 셋팅되어 있는데, (논리적인) 서비스 중 한 놈은 큰 용량의 자료를 클라이언트로부터 수신하여 처리하는 기능을 가지고 있는데 이 놈 때문에 다른 서비스의 질에 영향을 주고 싶지 않아 응용프로그램 풀을 분리하기로 결정했다.
IIS 상 웹사이트 하위 디렉터리를 응용프로그램으로 바꾸고 풀을 따로 설정한 후 실행하니 WCF 서비스가 동작하지 않는다.
문제는 라이브러리로 만들어진 서비스 dll을 찾지 못하는 것이다.
가만히 생각해보니, 하위 폴더를 독립된 응용프로그램 영역으로 만들었으니 이 폴더가 응용 프로그램 도메인 루트가 되어 더이상 웹 사이트 루트의 bin 폴더가 참조되지 않기 때문이다.
그래서 bin 폴더를 옮겨놓으니 잘 된다.
그러나 매번 빌드하고 bin 폴더를 옮기는 것은 매우, 아주, 심히, 귀찮은 일이다. 깜빡할 수도 있고...
VS의 빌드 이벤트는 이런 상황에 알맞은 해답을 제시해 준다. 바로 빌드이벤트 명령이다.
다음과 같이 빌드 후 이벤트 명령줄에 입력한다.
이젠 프로젝트를 빌드하면 하위 폴더에 자동으로 dll 들이 복사되어 신경 쓸 필요가 없게 되었다.
'.NET Framework' 카테고리의 다른 글
Security Context Token(SCT) Expired on WCF (0) | 2015.03.03 |
---|---|
Caching in WCF (2) | 2014.02.21 |
ASP.NET SignalR (0) | 2013.12.06 |
maxConcurrentSessions in WCF (0) | 2013.11.21 |
SQL Double Split (0) | 2013.11.13 |
그 규모의 크기에 상관없이, 리더는 책임감을 가지고 자신의 리딩 업무를 수시로 점검해야 할 것이다.
리더에게 주어진 것은 명령을 할 수 있는 권한이 아니다.
리더에게 부여된 권한은 책임에 수반되는 수단일 뿐이다.
따라서 책임이 없는 리더의 권한은 봉건사회 계급구조상의 비루한 권력과 다를바 없다.
프로젝트팀을 관리하는 리더의 책임은 무었일까? 리더가 구성원들의 모든 잘못에 책임을 져야 하는가?
여기서 언급하는 책임은 이러한 1차원적인 문제가 아니다.
제일 중요한 리더의 책임은 바로 '비전' 제시이다. 그 흔하디 흔한 말... '비전'이다.
식상할 정도로 자주 언급되는 이 말은 역설적으로 그 실체를 찾기 힘들 정도로 귀하디 귀하다.
흔히 어떤 일을 구체화 시킬 때 6하원칙에 입각하여 서술하곤 한다.
리더의 책임이라는 관점에서 가중 중요한 원칙은 바로 "왜(why)" 이다.
구성원들이 하는 '그일'에는 이유가 있어야 한다는 것이다. 이유도 모른채 혹은 이유가 공감되지 않은채 하는 일은 초등학생도 싫어하는데 하물며 성인이래야...
'왜(why)'가 뚜렷하다면, '무엇(what)'은 저절로 성립된다.
반면, 평범한 리더(리더라 부를 수 있을지 모르겠지만...)는 '어떻게(how)'에 집중한다.
구성원들에게 '이건 이렇게, 저건 저렇게...' 어떻게 하는지 알려 주고 싶어서 안달이다.
키 플레이어가 좋은 리더가 되기 힘든 대표적인 사례라 하겠다.
더 최악은 '누가, 언제, 어디서'에만 집중하는 리더이다. 사실 이런 부류는 리더라 부르면 안된다.
야근의 횟수로 역량의 척도로 판단하는 전형적인 예를 들 수 있겠다.
6하 원칙은 모두 중요하다.
하지만 훌륭한 리더가 되기 위해서는 '왜(why)'와 그에 맞는 '무엇을(what)'에 우선 집중해야 한다.
'어떻게(how)'는 그 다음이다.
조직의 핵심 가치에 공감한 구성원들이 그들의 열정과 호기심을 프로젝트에 불싸지르도록 하는 중요한 기준임을 명심하자!!!
스스로 반성해 볼 일이다.
'프로젝트관리' 카테고리의 다른 글
데브옵스 처방전 (0) | 2015.05.21 |
---|---|
개발자 칠거지악 (0) | 2015.02.06 |
로그수집에 대한 잡설(전수조사 vs 표본조사) (0) | 2013.09.05 |
공학의 ACE (0) | 2013.06.28 |
주석은 Why > What > How 순으로... (2) | 2013.06.12 |