3-Tier Application 혹은 N-Tier Application이 항상 빠른 것은 아니다. 오히려 대부분의 응용프로그램은 3-Tier 체계로 가면 느려질 수 있다. 여기서 3-Tier라는 것은 미들웨어를 넣는다는 개념이 아니라, 정확히 업무 영역이 데이터저장과 관련 애플리케이션/비즈니스 애플리케이션/프리젠테이션으로 나누어지는 것을 의미한다. N-Tier 응용프로그램을 이런 형식으로 구성하게 되면, 프로그램의 유지 보수가 훨씬 쉬워지게 된다.
근본적으로 윈도우 계열의 개발에서 애플리케이션이 명백하게 비즈니스 로직으로 나누어져 개발한 예는 국내에서 그렇게 찾아보기 쉽지 않다. 대부분은 COM 관련 코딩이 워낙 닭짓이라, 웹과 관계된 부분은 아예 별도의 애플리케이션으로 구성하고, C/S로 관리되는 부분은 아예 파워빌더나 비주얼 베이식으로 별도의 애플리케이션으로 운영하였다. 따라서, 이러한 방식은 모양만 3-Tier일 뿐이며, 실제는 2-Tier로 운영되는 셈이다.
따라서, 윈도우 계열에서는 여지껏 모양만 3-Tier인 애플리케이션이 대세로 자리잡았던 셈이다. 하지만, .NET 부터는 응용프로그램이 3-Tier 형식을 갖추는 데 별다른 장애가 없다. 정말 유닉스스러운(?) 개발 과정을 갖고 있기 때문에, 웹 응용프로그램을 개발함에 있어서, 마치 기존 유닉스 프로젝트를 수행하는 것처럼 해 나가면 되기 때문이다.
개발 환경이 이런 식으로 달라지면서 개발 방법은 다음 두 가지로 나누어진다.
- 전체 애플리케이션을 하나의 어셈블리로 개발하는 방법 : 애플리케이션을 하나의 어셈블리로 만들고, 네임스페이스를 부여한다.
- 애플리케이션을 기능적으로 조각내어, 기능을 따라 가는 방법 : 각 애플리케이션은 몇 개의 서브애플리케이션의 수평적 조합으로 이루어지는 형태로 작성된다. 각 조각은 별도의 어셈블리가 된다.
.NET에서는 이러한 개발 방법론 외에 몇 가지 방법론을 더 제시하지만, 근본적으로 닷넷프로젝트는 EJB 프로젝트의 구성과 무척이나 닮아 있다. 단, EJB가 전체에서 부분을 생각한다면 .NET은 부분에서 전체로 이어지는 방식을 사용하게 되는 것이 차이점이다.
Code Behind와 같은 괴상한 개념의 출현
사실상 ASP.NET은 프리젠테이션의 일부일 뿐이다. 하지만, 현존하는 많은 ASP.NET과 관계된 기사들은 대부분 프리젠테이션으로 ASP.NET이 아닌, 그 자체로만 ASP.NET을 보고 있다. 즉 3-Tier의 전면에 서서 "도대체 DB 로직이나 애플리케이션 로직이 어떻게 돌아가는지 모르겠는데, 어쨌든 이 메소드를 호출하면 이런 값이 나올 것이야!" 라는 개념만 알고 있다면 프리젠테이션의 역할은 끝난다고 볼 수 있다. 이 경우 코드를 숨기는 코드 비하인드는, 프로그램의 가독성을 심각하게 떨어뜨릴 수도 있다. 이러한 것이 C에서의 include 개념과 같다고 생각하면 안 된다. include는 공통의 개념을 반복하는 반복성 닭질을 줄이자는 것에 의미가 있지만 코드 비하인드는 단순히 코드를 숨기는 것 이외의 장점은 존재하지 않는다. (물론, 디자인과 코드가 분할되면 디버깅 등의 작업이 용이하다는 MS측의 말이 있긴 하지만, 디자인과 코드의 분할은 Mission Impossible에 가깝다.)
분할 방법
3-Tier 응용프로그램은 일단 기능적으로 분할하는 방법이 가장 편리하게 쓰인다. 이러한 개념은 .NET보다는 EJB 진영에서 많이 고민하고, 발전시켰으며, .NET은 EJB보다는 훨씬 더 분산적인 방법을 사용하는 것이 좋다. .NET 프레임워크가 하나의 EJB 컨테이너로 간주되고, EJB 컴포넌트를 .NET 어셈블리로 생각하면 문제는 쉽게 풀린다. 물론, 이렇게 1:1 로 대응시키기엔 개념상의 다소 무리가 따르기는 하지만, .NET 자체는 J2EE의 영향을 무척 많이 받은 것은 사실로 보인다.
어셈블리 DLL
그렇다면 .NET N-Tier Application의 구체적인 구현 방식은 데이터베이스와 관계된 많은 작업을 수행하는 어셈블리 DLL과, 어셈블리 DLL에서 메소드를 호출하는 프리젠테이션 영역으로 나누어진다고 볼 수 있다. 어셈블리는 전역 어셈블리와 지역 어셈블리로 나뉘며, C/S와 Web이 동시에 작동하는 환경이라면 전역 어셈블리쪽으로 DLL을 등록한다. 하지만, 3-Tier이면서 서비스와 운영 및 관리가 별도로 분리되고, 전부 웹 기반 하에서 작동한다면 웹 기반의 지역 어셈블리 쪽이 훨씬 이득을 볼 수 있다. 물론, 이 모든 것은 선택의 문제이다.
[출처 : 윈도우사용자그룹]