헝그리코더

함수 선언식과 표현식의 차이점

함수 선언식은 호이스팅에 영향을 받지만, 함수 표현식은 호이스팅에 영향을 받지 않는다.

함수 선언식은 코드를 구현한 위치와 관계없이 자바스크립트의 특징인 호이스팅에 따라 브라우저가 자바스크립트를 해석할 때 맨 위로 끌어 올려진다.

예를 들어, 아래의 코드를 실행할 때

//[실행 전]
funcDeclaration();
funcExpression();
 
function funcDeclaration() {
    return console.log('함수 선언식 [ Function Declarations ]');
 }
var funcExpression = function () {
    return console.log('함수 표현식 [ Function Expressions ]');
}

호이스팅에 의해 자바스크립트 해석기는 코드를 아래와 같이 인식한다.

위 코드 결과

함수 표현식 funcExpression 는 호이스팅이 적용되며 위치가 상단으로 변경되었다.

   var funcExpression;

   funcDeclaration();
   funcExpression();

함수 표현식 funcExpression 에  할당될 함수 로직은 호출된 이후에 선언되므로, funcExpression 는 함수로 인식하지 않고 변수로 인식하게된다.

1. IIS
* IIS의 pipe line mode
> ISAPI mode : class mode라고도 불리우며, 이는 file의 확장자를 기준으로 ISAPI 확장에 의하여 처리된다.
> Integrated mode : .NET이 pipe line의 일부이기 때문에 특정 file의 확장자와 관련된 어떠한 ISAPI mode가 필요하지 않는다.

System.Web.Routing.UrlRoutingModule 에 의하여 Url의 Routing이 처리가 된다.
이는 Url의 모든 파일이나 내용이 .NET에 의하여 관리되는 것을 의미한다.

2. Routing
System.Web.Routing.UrlRoutingModule은 요청을 받는 즉시 System.Web.Routing을 실행한다.
Routing의 역활은 먼저, Disk의 파일과의 연관성을 찾아내고 파일과의 연관성이 없는 경우, URL 패턴을 인식하고 분석하여 내부 Component가 사용할 수 있는 Request context 데이터 구조를 구성한다. 파일과의 연관성이 발견되는 경우, 파일에 대하여 실행이 되게 된다. 정적 resource 파일들(*.jpg와 같은 그림 파일이나 html 파일들)에 대하여 제공 및 aspx 파일에 대한 WebForm 실행이 이루어진다. 
Routing 구성은 System.Web.Routing.RouteTable이라는 static collection안에 놓여진다. 그 Collection안의 entry는 서로 다른 URL pattern을 표현하는데 이 부분의 경우에는 Global.asax 파일안에 RegisterRoutes() method로 사용자가 구성이 가능하다. 

3. Controller & Action
기본적으로 MvcRouteHandler라는 Routing 처리기를 이용해서 구성이 되며, Routing 결과에 따라 ControllerFactory에서 Controller를 생성하게 된다. 이 과정에서 MvcRouterHandler는 MVC Controller를 찾아내고, Action method의 매개변수를 제공한다. 이 과정은 Assembly reflection을 이용하고 있으며 모든 IController interface를 가지고 이름이 *Controller로 끝이 나는 모든 public class를 ControllerFactory에 등록하고, 들어온 URL 결과에 따라 특정 Controller를 실행하고, 그에 맞는 Action method를 실행한다. 따라서, Controller에서 직접 Response를 제어할 수 있으나, MVC에서는 이를 권장하지 않는다. MVC에서는 계획된 출력을 의미하는 ActionResult 객체를 반환하는 것이 권장된다. 

4. ActionResult & View
Controller에서 제공된 ActionResult를 이용하여 View를 Render하는 과정이다. 기본적으로 View의 Render는 IViewEngine을 구현하는 .NET class를 통해서 구현되는데 기본적으로 WebFormViewEngine을 사용한다. 이름을 보면 알 수 있듯이 이는 기존의 WebForm이 Render 될 때 사용되는 View Engine과 동일하다. 그러나 MVC의 '관계의 분리' 개념에 따라 View는 HTML을 생성하는 것 이외에는 어떠한 일을 하지 않는다. 

* 분석 함수 (통계)

-- Pivot / UnPivot
-- 한 열에 포함된 여러 값을 출력. 컬럼으로 변환하여 테이블 반환 식을 회전하고 
-- 필요하면 집계까지 수행할 수 있다.

SELECT *
FROM MemberGame
Pivot( Sum(cash) -- 집계 함수(열)

    For userLevel -- 새로운 컬럼으로 변경할 컬럼명

    In ([1],[2],[3],[4],[5]) -- 컬럼 목록

) AS resultPivot; -- 피벗 이름


-- SQL Server 2012부터 제공
-- 다음 행과의 값의 차이 : LEAD(컬럼명, 다음 행 위치, 다음 행이 없을 경우 자기자신)

SELECT userXp, userXp - (LEAD(userXp, 1,0) OVER(Order By userXp Desc)) as [다음 회원과 userXp 차이], *
FROM MemberGame


-- 이전 행과의 값의 차이 : LEAD(컬럼명, 이전 행 위치, 이전 행이 없을 경우 자기자신)
SELECT userXp, userXp - (LAG(userXp, 1,0) OVER(Order By userXp Desc)) as [이전 회원과 userXp 차이], *
FROM MemberGame


-- 그룹의 가장 큰 값과의 차이
SELECT userLevel, userXp, userXp - (FIRST_VALUE(userXp) OVER(Partition By userLevel Order by userXp Desc)) as [다음 회원과 userXp 차이], *
FROM MemberGame


-- 누적 합계 (자신의 값과 같거나 큰 경우)
SELECT userLevel, userXp, (CUME_DIST() OVER(Partition By userLevel Order by userXp Desc)) * 100 as [누적인원 백분율%], *
FROM MemberGame




-- 그룹별 중앙값 계산
SELECT Distinct userLevel, PERCENTILE_CONT(0.5) Within Group(Order By userXp) Over(Partition By userLevel) as [userLevel 별 중앙값]
FROM MemberGame 

-- PERCENTILE_CONT 0.0~1.0 사이의 백분율 (0.5이면 정확히 중간값)
-- Error : 현재 호환성 모드에서는 PERCENTILE_CONT 함수를 사용할 수 없습니다. 110 모드 이상에서만 허용됩니다.


-- 그룹별 중앙위치 계산
SELECT Distinct userLevel, PERCENTILE_DISC(0.5) Within Group(Order By userXp) Over(Partition By userLevel) as [userLevel 별 중앙값]
FROM MemberGame 
-- PERCENTILE_CONT 0.0~1.0 사이의 백분율 (0.5이면 정확히 위치값)
-- Error : 현재 호환성 모드에서는 PERCENTILE_CONT 함수를 사용할 수 없습니다. 110 모드 이상에서만 허용됩니다.

항상 구글링 하기 귀찮아서..

출처 : http://blog.naver.com/diceworld/220156570441