ASP .NET vs Razor (개발자를 위한 작동 원리)

1.1 ASP.NET

ASP.NET은 그 시작부터 Microsoft의 웹 개발 프레임워크의 중추였습니다. 강력한 .NET Framework를 기반으로 구축되어 개발자가 .NET MVC (모델 뷰 컨트롤러) 패턴을 통해 웹 응용 프로그램에 대한 완전한 제어를 제공합니다. ASP.NET Core MVC 프레임워크는 복잡한 아키텍처 패턴과 광범위한 사용자 정의가 필요한 웹 응용 프로그램을 구축하는 데 뛰어납니다.

1.2 Razor

Razor는 ASP.NET Core 생태계의 일부로 소개된 현대적인 웹 개발 접근 방식을 나타냅니다. HTML과 서버 쪽 코드 통합을 간소화하는 강력한 뷰 엔진입니다. Razor Pages는 웹 개발을 보다 직관적이고 간단하게 만드는 페이지 중심 시나리오를 제공합니다.

3.1 아키텍처 접근 방식

아키텍처 패턴은 이러한 접근 방식 간의 가장 근본적인 차이를 나타냅니다. ASP.NET Core MVC는 세 가지 상호 연결된 구성 요소를 가진 전통적인 모델 뷰 컨트롤러 패턴을 따릅니다. 각 요청은 적절한 MVC 컨트롤러에 대한 라우팅 시스템을 통해 흐르며, 이는 모델과 상호 작용하고 적절한 뷰를 선택합니다.

반면, Razor Pages는 더 간단한 페이지 중심 접근 방식을 채택합니다. 각 Razor 페이지에는 데이터 모델과 사용자 입력을 처리하는 자체 PageModel 클래스가 있습니다. 이 구조는 대규모 컨트롤러 클래스를 제거하고 양식 제출 및 데이터 바인딩을 간소화합니다.

3.2 요청 처리 패턴

요청 처리 패턴은 두 가지 사이에서 크게 다릅니다. MVC에서는 요청이 뷰를 반환하는 액션이 있는 컨트롤러를 통해 라우트됩니다. 일반적인 MVC 컨트롤러 코드는 다음과 같습니다:

public class HomeController : Controller
{
    public string Message { get; private set; }

    public IActionResult Index()
    {
        // Return the view associated with this action
        return View();
    }
}

public class HomeController : Controller
{
    public string Message { get; private set; }

    public IActionResult Index()
    {
        // Return the view associated with this action
        return View();
    }
}

Public Class HomeController
	Inherits Controller

	Private privateMessage As String
	Public Property Message() As String
		Get
			Return privateMessage
		End Get
		Private Set(ByVal value As String)
			privateMessage = value
		End Set
	End Property

	Public Function Index() As IActionResult
		' Return the view associated with this action
		Return View()
	End Function
End Class

한편, Razor Pages는 OnGet 및 OnPost와 같은 메서드를 사용하여 PageModel에서 요청을 직접 처리합니다:

public class IndexModel : PageModel
{
    public string Title { get; private set; }

    public void OnGet()
    {
        // Handle GET request and initialize data for the view
    }
}

public class IndexModel : PageModel
{
    public string Title { get; private set; }

    public void OnGet()
    {
        // Handle GET request and initialize data for the view
    }
}

Public Class IndexModel
	Inherits PageModel

	Private privateTitle As String
	Public Property Title() As String
		Get
			Return privateTitle
		End Get
		Private Set(ByVal value As String)
			privateTitle = value
		End Set
	End Property

	Public Sub OnGet()
		' Handle GET request and initialize data for the view
	End Sub
End Class

3.3 페이지 구성 및 구조

Razor Pages는 페이지 폴더 구조에서 각 페이지가 자신의 뷰와 모델로 독립적으로 존재하도록 코드를 구성합니다. 그러나 MVC는 이들에 대한 관심사를 모델, 뷰, 컨트롤러 폴더로 나눕니다. 이 근본적인 차이는 개발자가 코드 구성 및 유지 관리를 하는 방식에 영향을 미칩니다.

3.4 데이터 흐름 및 바인딩

MVC는 컨트롤러 동작, 모델 바인딩 및 뷰 렌더링을 통해 데이터 흐름을 구현하며 각 단계를 명시적으로 제어합니다. Razor Pages는 양방향 데이터 바인딩과 PageModel을 통한 자동 모델 바인딩을 통해 이를 간소화합니다. 이로 인해 Razor Pages에서는 폼 제출 및 유효성 검사 오류 처리가 더 간단하게 이루어집니다.

3.5 구성 요소 재사용성

두 프레임워크 모두 뷰 컴포넌트와 태그 헬퍼를 지원하지만, 재사용성에 접근하는 방식이 다릅니다. MVC는 부분 뷰와 자식 동작을 통해 더 세밀한 제어를 가능하게 하지만, Razor Pages는 페이지 기반 구성 요소 및 공유 레이아웃을 강조합니다. MVC 패턴은 다양한 뷰에서 재사용 가능한 구성 요소를 생성할 수 있는 더 많은 옵션을 제공합니다.

3.6 개발의 복잡성

두 접근 방식 간의 학습 곡선 및 개발 복잡성은 크게 다릅니다. MVC의 세 가지 상호 연결된 구성 요소를 통한 관점 분리는 초기 설정이 더 필요하지만 더 큰 유연성을 제공합니다. Razor Pages의 단순화된 구조는 시작하기 더 쉽지만 복잡한 시나리오에서는 추가 작업이 필요할 수 있습니다.

4.1 ASP.NET Core MVC의 장점

• MVC 프레임워크는 분리된 관심사 및 복잡한 아키텍처 패턴이 필요한 상황에서 뛰어납니다.
• 개발자에게 애플리케이션 구조에 대한 완전한 제어를 제공합니다.
• 광범위한 사용자 정의가 가능합니다.
• 성숙한 생태계는 REST API 처리를 위한 강력한 솔루션을 제공합니다.
• 종속성 주입 및 복잡한 라우팅 시나리오에 대한 강력한 지원을 제공합니다.
• MVVM 솔루션 패턴이 잘 지원됩니다.
• 동적 서버 뷰를 효율적으로 처리합니다.
• 태그 헬퍼와 뷰 컴포넌트는 재사용 가능한 UI 구성 요소를 구축하기 위한 강력한 도구를 제공합니다.

4.2 ASP.NET Core MVC의 단점

• 초보자에게 가파른 학습 곡선이 있습니다.
• MVC 패턴의 상호 연결된 구성 요소를 이해하는 데 어려움이 있습니다.
• 대규모 응용 프로그램에서 큰 컨트롤러 클래스를 관리하는 것이 어려울 수 있습니다.
• 관심사의 분리는 유익하지만 복잡성을 증가시킬 수 있습니다.

4.3 Razor Pages의 장점

• 페이지 중심 시나리오에서 뛰어난 성과를 냅니다.
• 더 작은 웹 애플리케이션에 적합한 단순화된 개발 모델을 제공합니다.
• 양방향 데이터 바인딩 및 폼 제어에 강력한 지원을 제공합니다.
• 유효성 검사 오류 및 AJAX 호출에 대한 내장 지원을 제공합니다.
• 페이지 폴더 구조를 통한 명확한 조직이 가능합니다.
• HTML과 서버 측 코드를 혼합하기 위한 직관적인 Razor 구문을 제공합니다.
• 폼 제출 및 사용자 입력을 처리하는 간단한 접근 방식을 제공합니다.
• 개발 시간을 단축할 수 있습니다.

4.4 Razor Pages의 단점

• 광범위한 아키텍처 패턴이 필요한 복잡한 애플리케이션에는 최적이 아닐 수 있습니다.
• 페이지 모델 접근 방식은 MVC 컨트롤러에 비해 유연성을 제한할 수 있습니다.
• 간단한 아키텍처는 Enterprise 수준 애플리케이션에 잘 확장되지 않을 수 있습니다.
• 복잡한 라우팅 및 컨트롤러 로직이 요구되는 애플리케이션에는 덜 적합할 수 있습니다.