헝그리코더

기본적으로 매니지드 언어에서는 가비지 컬렉터에  모든 리소스를 자동으로 관리한다고 소개하고 있다. 
하지만 예외로 외부의 비관리 영역상의 자원에 대해서는 관리 되지 않는 부분이 있는데.

파일 핸들

메모리 핸들

데이터베이스 연결

소켓 핸들

스레드 핸들

세마포어

등 비관리 자원들에 포함 된다.

C# 에서 네임스페이스에 쓰이는 using 아닌 , 비구조적 예외 처리에 쓰이는 using 문이 있는데

코드를 한번쯤 다뤄본 경험이 있다면 작성된 using 문을 본 경험이 있으실거라 생각한다.

데이터 베이스 연결 부분을 예시로 들어 본다고 한다면.

using (SqlConnection connection =new SqlConnection(connectionString))
{
    SqlCommand command =new SqlCommand(queryString, connection);
    command.Connection.Open();
    command.ExecuteNonQuery();
}

using{  } 범위에서의 자원들은 영역에서 벋어 나게 되면 자원을 반납하게 되며 해당 범위에서

예외(오류) 생기더라도 자동적으로 자원을 반납되게 된다.

하여 비관리 영역상의 자원 관리는 선택적인 사항이 아니라, 반드시 숙지하고 활용해야 할 사항이다.

만약 집중되어 사용량이 몰릴 경우 자원이 고갈되어 시스템에 문제가 생길 수 있기 때문에

이를 사전에 예방하고 효율적으로 관리하기 위해서 명시적인(IDisposable 인터페이스) 소멸자를 직접 구현하거나

앞서 설명 하고 있는 using 문을 사용한 외부 비관리 자원들의 관리를 해야 한다.

참조:msdn https://docs.microsoft.com/en-us/archive/msdn-magazine/2004/february/comparing-the-timer-classes-in-the-net-framework-class-library

.NET Framework 클래스 라이브러리는

  System.Windows.Forms.Timer

 , System.Timers.Timer

 , System.Threading.Timer 의 세 가지 타이머 클래스를 제공 하고 있음. 

이러한 각 클래스는 서로 다른 상황에서 사용하도록 설계되고 최적화되어 있음으로

그 차이점 을 간략히 메모 하기로 했다.

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을 생성하는 것 이외에는 어떠한 일을 하지 않는다.