Blazor는 JavaScript 대신 C #을 사용하여 대화형 웹 UI를 구축 할 수있는 새로운 프레임 워크입니다. 완전히 새로운 언어를 배우지 않고 기존의 기술을 웹 개발에 활용하려는 .NET 개발자에게 탁월한 옵션입니다. 그러나 JavaScript 개발자라면 어떨까요? Blazor가 JavaScript 개발자에게 제공할 것이 있을까요? Vue, React, 또는 Angular를 고수하는 것이 더 좋을까요?

JavaScript 개발자의 관점에서 Blazor를 살펴 보겠습니다.

이 포스팅에서는 다음의 내용을 다룰 것입니다.

• Blazor와 JavaScript 비교
• Blazor와 ASP.NET Core MVC 응용 프로그램 비교
• 클라이언트 측 Blazor의 장점
• 클라이언트 측 Blazor의 단점
• 현재 Blazor 도구 및 지원
   

Blazor 앱의 구조, 작동 방식, 잠재적 용도 및 JavaScript와의 차이점을 살펴 보겠습니다. 마지막으로 Blazor의 실제 작동 방식을 보여주는 간단한 앱을 살펴 보겠습니다.

Blazor 란?

WebAssembly를 언급하지 않고 Blazor를 소개할 수 없습니다.

WebAssembly (또는 간단히 "wasm")는 2015 년에 발표된 웹 브라우저에 대한 개방형 표준입니다. 클라이언트 및 서버 애플리케이션을 웹에서 컴파일 할 수 있는 이식 가능한 대상으로 설계된 컴팩트 이진 코드 포맷으로 설명됩니다.

이 발표 이,후 일부 조직에서는 WebAssembly 위에서 고급 프로그래밍 언어를 실행할 수 있는 프로젝트를 시작했습니다. Microsoft는 Blazor 프로젝트를 시작하여 주도권을 잡았으며 이제 클라이언트 측 웹 앱에서 Blazor를 사용하여 C #을 실행할 수 있습니다. WebAssembly 개방형 표준 사양 덕분에 .NET 코드는 플러그인없이 브라우저에서 실행될 수 있습니다.

Blazor는 C #을 전체 스택으로 사용하는 SPA (Single-Page Applications) 용 프런 엔드 개발 프레임 워크입니다. Blazor가 ASP.NET Core 서버 코드와의 결합을 대체할 것이므로, jQuery, React 또는 Angular처럼 JavaScript에 의존하지 않고 C #으로 클라이언트 측 애플리케이션 코드를 작성할 수 있습니다. 이를 통해, 이제 .NET end-to-end 방식이 가능해집니다.

Blazor 컴포넌트는 C # 클래스로 작성된 다음 .NET 어셈블리에 내장되어 있으며, 입력 및 출력 작업 (사용자 이벤트 처리 및 UI 렌더링)을 담당합니다. 컴포넌트는 Razor 클래스 라이브러리 또는 NuGet 패키지와 같은 여러 앱 및 플랫폼에서 재사용하거나, 공유 및 배포되는 컨테이너로 작동할 수도 있습니다. Razor는 HTML 및 C #을 사용하여 동적 웹 페이지 프로그래밍을 허용하는 웹 개발 구문입니다.

클라이언트 측 로직을 수행하기 위한 JavaScript 함수가 포함된 HTML 페이지는 프론트엔드 개발자에게 친숙합니다. 마찬가지로, 일반적인 Blazor 컴포넌트는 HTML 렌더링 및 이벤트 처리를 담당하는 C# 코드와 함께 HTML 요소를 포함하는 태그 파일 (.razor 확장명)로 선언됩니다.

Blazor와 JavaScript의 차이점

Blazor는 재사용 가능한 웹 UI 구성 요소를 통해 코드 캡슐화를 제공합니다. Blazor는 또한 클라이언트 및 서버 C # 코드가 코드와 라이브러리를 공유할 수 있도록 합니다.

컴포넌트화는 React, Angular 및 기타 JavaScript 프레임워크를 사용하는 사람들에게 친숙한 개념입니다. 컴포넌트는 앱의 빌딩 블록이며 일반적인 앱에는 이러한 컴포넌트가 많이 있습니다. 선택적으로 입력을 허용하고 UI 섹션이 표시되는 방법을 설명하는 HTML 요소를 반환합니다.

ASP.NET Core는 Razor 컴포넌트 형태로 이 아이디어를 제공합니다. Razor 컴포넌트도 Blazor의 컴포넌트 모델입니다. 따라서 Blazor 구성 요소와 Razor 컴포넌트는 서로 바꿔 사용할 수 있습니다.

각 Blazor 컴포넌트는 애플리케이션 UI 구조에서 장바구니, 뉴스 피드 또는 설명 섹션과 같은 다른 요소를 나타냅니다.

Blazor와 ASP.NET Core MVC 애플리케이션의 차이점

보통 ASP. NET Core MVC는 UI를 문자열 블록으로 렌더링합니다. 반면에 Blazor는 문자열이 아니라 메모리에 보관된 DOM (Document Object Model)으로 표현되는 렌더트리를 만듭니다. Blazor는 그 표현을 유지합니다. 바인딩 값이 업데이트 될 때와 같이 변경 사항이 생기면 영향을 받는 DOM 요소에 대한 UI 업데이트가 트리거됩니다. 이것이 ASP.NET Core HTML Helpers 및 문자열을 렌더링하는 Razor Views의 큰 차이점입니다.

그렇다면 왜 Blazor는 문자열 대신 렌더 트리를 사용할까요? Blazor 코드(일반적으로 wasm 코드)는 DOM 요소에 직접 액세스할 수 없습니다. 이러한 한계는 UI 요소에 대한 전체 액세스 권한을 얻기 위해 JavaScript에 의존하는 ASP.NET Core HTML Helpers 및 Razor Views와 다릅니다.  따라서, Blazor는 트리를 렌더링하여 DOM 표현으로 돌아가 특정 DOM 부분을 찾은 다음, 업데이트, 편집, 삭제 등의 작업을 수행합니다. Blazor 프레임 워크는 데이터 모델의 변경 사항을 듣고 렌더 트리를 조작하여 변경 사항을 적용합니다. 이 메커니즘은 C #이 클라이언트 쪽에서 작동하도록 합니다.

그러나 순수한 클라이언트 측 JavaScript 또는 ASP. NET Core MVC/Razor가 아닌 Blazor로 개발해야 하는 이유는 무엇일까요? 새로운 Blazor 프로젝트를 개발하기 전에 결정을 내릴 수 있도록, 이들 간의 차이점에 대해 논의하겠습니다.

클라이언트측 Blazor의 장점

1. Blazor를 사용하면 .NET 코드를 브라우저에서 직접 실행할 수 있습니다. .NET 개발자는 polyglot 프로그래밍을 할 필요가 없기 때문에 풀 스택 전문가들의 JavaScript / Node.JS 독점을 막을 수 있습니다. JavaScript 코드를 작성하지 않고도 완벽한 솔루션을 만들 수 있습니다.
   
   

2. Blazor 코드는 .NET Intermediate Language로 컴파일되므로 동등한 JavaScript 코드보다 빠를 가능성이 있습니다. 이 컴파일 모델은 게임과 같은 성능 중심 브라우저 애플리케이션을 차별화 할 수 있습니다.
   
   

3. 클라이언트와 서버 앱 간에 유효성 검사 코드를 공유 할 수 있습니다. 브라우저와 백엔드 모두에 적용할 양식 유효성 검사 논리가 있다면, Blazor를 사용하여 .NET Standard 2.0에서 클래스 라이브러리를 만들고 클라이언트 및 서버 앱간에 공유 할 수 있습니다. 유효성 검사 논리의 변경 사항은 두 플랫폼 모두에 자동으로 적용됩니다.
    

클라이언트 측 Blazor의 단점

1. 브라우저에서 Blazor를 실행하려면 애플리케이션의 .wasm 및 .NET 라이브러리를 브라우저로 다운로드해야 할뿐만 아니라 Blazor가 실행되는 .NET 런타임인 ​​Mono.wasm도 다운로드해야 합니다. Mono.wasm은 캐시 될 수 있지만 처음 다운로드할 때에는 애플리케이션 시작이 지연됩니다. 따라서 작은 Blazor 애플리케이션에서도 메가 바이트의 코드를 다운로드해야 합니다. JavaScript에는 이러한 오버 헤드(간접적인 처리 시간)가 없습니다.
   
   

2. Blazor는 DOM 요소를 직접 조작 할 수 없습니다. 경우에 따라 클라이언트 앱은 HTML 요소를 많이 제어해야 하지만, Blazor는 이 기능을 자체적으로 제공하지 않기 때문에 JavaScript Interop을 사용해야 합니다.
   
   

3. 전반적인 클라이언트 측 Blazor는 현재 앱 실행의 대부분의 측면에서(시작 뿐만 아니라) 현재 JavaScript보다 느립니다. Microsoft는 성능 향상을 위해 노력하고 있으며, 다른 플랫폼에서 성능 튜닝 작업을 수행한 이력을 감안할 때, 시간이 지남에 따라 이러한 문제를 해결할 수 있을 것입니다.
    

현재 디버깅 기능이 제한되어 있다는 점도 주목할 가치가 있습니다. 이 부분에서 Blazor는 여전히 개선되어야 합니다. Chrome의 디버깅 탭을 사용하여 int, bool 및 string 유형의 값을 디버깅 및 검사 할 수 있습니다. 보다 효과적으로 디버깅하려면 클라이언트 애플리케이션 전체에 콘솔 로깅을 넣어야 합니다.

Blazor의 양면

우리는 보통 Blazor에 대해 브라우저에서 WebAssembly 위에서 실행되는 C # 코드로 이야기하지만 그것은 절반에 지나지 않습니다. 전체 그림을 보려면 이러한 앱을 Blazor 클라이언트 측 또는 Blazor 서버 측으로 실행하도록 만들 수 있다는 점을 이해해야 합니다. 앱을 만들 때 먼저 호스팅 모델 중 하나를 선택합니다. 이 구성은 애플리케이션이 동일하게 유지되는 경우에도 애플리케이션이 후드에서 작동하는 방식을 크게 변경합니다.

Blazor 클라이언트 측은 JavaScript 개발자에게 친숙한 호스팅 모델입니다. 개발자는 앱 자산을 웹 서버에 배포하여 일련의 정적 파일로 클라이언트 브라우저를 제공할 수 있습니다. 브라우저가 이러한 파일을 다운로드한 후 앱은 WebAssembly 위에서 실행될 수 있습니다. 이 동작은 앱이 JavaScript 대신 WebAssembly에서 실행된다는 점을 제외하고 클라이언트 측 JavaScript 앱과 크게 다르지 않습니다.

다음으로 서버 측 Blazor에 대해 이야기하겠습니다.

Blazor 서버 측 앱은 서버에서만 실행되며 WebSocket 기반의 실시간 통신 라이브러리인 ASP.NET Core SignalR 기반으로 구축됩니다. Blazor 서버 측은 앱이 브라우저에서 실행될 때 WebAssembly에 의해 부과되는 제한 없이, 전체 ASP.NET Core web framework 위에 있는 서버에서 실행될 수 있습니다.

현재 Blazor 도구 및 지원

Microsoft가 Blazor를 시작했을 때는 브라우저에서 실행될 수 있는 .NET 단일 페이지 앱을 위한 실험적인 프레임워크였습니다. 그러나 Microsoft는 Blazor를 지원되는 웹 UI 프레임 워크로 제공하려고 합니다. Windows, Linux 및 Mac OS에서 지원되며 ASP.NET의 기능으로 Microsoft에서 배포합니다. 웹 개발의 주력 회사인 ASP.NET Core 파이프라인에는 공식 롤아웃에 Blazor가 포함되었습니다.

샘플 Blazor 앱 만들기

실습 준비가 되셨다면, Blazor의 작동 방식을 보다 명확하게 이해하기 위해 다음 단계들을 수행하실 수 있습니다.

우선, 최신 .NET Core 3.0 Preview SDK 릴리스를 설치합니다.

명령 쉘에서 다음 명령을 실행하여 Blazor 템플릿을 설치합니다.

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview9.19424.4 

Visual Studio Code 와 최신의 C# for Visual Studio Code 확장 프로그램을 설치하거나, Visual Studio 2019 Preview를 설치합니다 .

Blazor의 가장 기본적인 형태는 클라이언트 프로젝트만 필요하지만, 서버 측 백엔드 프로젝트에 대한 클라이언트 측 경험을 원하므로 명령 쉘에서 다음 명령을 실행합니다.

dotnet new blazorwasm -o BlazorClientServer --hosted 

Visual Studio에서 BlazorClientServer.sln 솔루션을 열거나,
Visual Studio Code에서 BlazorClientServer 폴더를 엽니다.

솔루션을 실행합니다.

브라우저에서 https://localhost:5001로 이동합니다.

아래와 같은 애플리케이션 홈페이지를 볼 수 있습니다.

이제 다른 두 메뉴인 Counter 및 Fetch Data로 이동합니다.

이것은 일반적인 ASP.NET Core MVC 웹 사이트와 비슷합니다. Blazor 솔루션은 JavaScript를 C# Code로 대체하는 ASP.NET Core의 새로운 형태라고 생각할 수 있습니다.

이제, 이전에 생성된 솔루션에 포함된 프로젝트를 자세히 살펴 보겠습니다.

BlazorClientServer.Client는 .NET Standard 2.0으로 작성된 프로젝트입니다. 브라우저 내부에서 실행되는 Blazor 페이지 및 컴포넌트를 포함하고 사용 중에 페이지를 다시 로드할 필요가없는 SPA입니다.

BlazorClientServer.Server는 HTTP API 서비스를 위한 ASP.NET Core 프로젝트입니다. 브라우저에서 요청한대로 일기 예보 데이터를 반환하기 위한 컨트롤러와 작업을 보유합니다.

BlazorClientServer.Shared는 클라이언트 및 서버 프로젝트 모두에서 사용되는 WeatherForecast 클래스를 포함하는 .NET Standard 2.0 프로젝트입니다.

애플리케이션을 실행하면 BlazorServer.Client.dll 어셈블리가 컴파일되어 localhost에 배포되지만 웹 서버는 이를 실행하지 않습니다. 대신 localhost는 브라우저가 이 파일을 요청할 때까지 기다립니다. 다운로드시 이 어셈블리는 브라우저에서 WebAssembly로 로컬로 실행됩니다.

그러면 브라우저는 언제 이 파일을 다운로드할까요? index.html을 보면 BlazorServer.Client.dll을 참조하지 않는 것을 볼 수 있습니다. 대신 blazor.webassembly.js의 URL을 지정합니다.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" /> 
  <meta name="viewport" content="width=device-width" /> 
  <title>BlazorClientServer</title> 
  <base href="/" /> 
  <link href="css/bootstrap/bootstrap.min.css" rel="stylesheet"> />
  <link href="css/site.css" rel="stylesheet" />
</head>
<body>
  <app>Loading...</app>
  <script src="_framework/blazor.webassembly.js"></script>
</body>
</html>

그런데, Blazor에는 JavaScript가 필요하지 않습니다. 그래도 Mono.wasm 런타임, .NET DLL 및 애플리케이션 DLL을 다운로드하려면 blazor.webassembly.js 파일이 필요합니다. 이러한 자산을 다운로드하면 애플리케이션을 웹 어셈블리로 실행할 수 있습니다.

Blazor 컴포넌트 트리의 최상위 요소는 App.razor 파일에 정의되어 있습니다. Blazor 템플릿에서 제공하는 아래 라우터 컴포넌트는 기본 레이아웃을 MainLayout으로 설정합니다.

<Router AppAssembly="@typeof(Program).Assembly"> 
  <Found Context="routeData">
    <RouteView RouteData="@routeData"
DefaultLayout="@typeof(MainLayout)" />
  </Found>
  <NotFound> 
    <LayoutView Layout="@typeof(MainLayout)">
      <p>Sorry, there's nothing at this address.</p>
    </LayoutView>
  </NotFound>
</Router>

위에서 본 것은 React, Angular 또는 Vue.JS와 같은 컴포넌트 기반 프레임워크에서 예상할 수 있는 것과 같은 컴포넌트로 구성된 구조입니다. 각 컴포넌트는 분리된 .razor 파일에 정의되어 있습니다.

MainLayout 컴포넌트는 CSS 클래스를 사용하여 일반 HTML 코드로 레이아웃 구조를 정의합니다. 애플리케이션 레이아웃은 사이드바 메뉴와 중앙 페이지 본문으로 표시됩니다.

@inherits LayoutComponentBase
<div class="sidebar">
  </NavMenu>
</div>
<div class="main">
  <div class="top-row px-4">
      <a href="http://blazor.net" target="_blank" class="ml-md-auto">About</a>
    </div>
    <div class="content px-4">
      @Body
    </div>
</div>

위의 MainLayout 컴포넌트는 다른 LayoutComponentBase에서 상속됩니다. 상속을 통해 컴포넌트는 보다 기본적인 컴포넌트를 기반으로 구축할 수 있으며, 코드 중복을 줄이고 앱 개발을 단순화합니다. 본문은 레이아웃 내에서 렌더링되는 RenderFragment입니다.

public abstract class LayoutComponentBase : ComponentBase 
{ 
        protected LayoutComponentBase(); 
        // 
        // Summary: 
        //      Gets the content to be rendered inside the layout. [Parameter] 
        public RenderFragment Body { get; set; } 
} 

사용자 인터페이스의 일부를 렌더링하는 컴포넌트 외에도 Blazor는 일반 HTML 응용 프로그램과 같은 페이지 개념을 가지고 있습니다. 이제, 카운터와 IncrementCount 버튼이 있는 간단한 페이지를 볼 수 있습니다.

@page " /counter"
<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
    int currentCount = 0;
    void IncrementCount ()
    {
      currentCount++;
    }
}

이 페이지는 일반 HTML 페이지와 어떻게 다를까요?

첫 번째 줄에는 @page “/ counter”와 같은 페이지 지시문이 있습니다. 페이지로 처리할 파일을 선언할 뿐만 아니라 사용자가 "/ 카운터"경로를 요청할 때마다 이 페이지가 렌더링되도록 정의합니다.

@currentCount는 HTML 내에서 currentCount 변수를 간단히 렌더링하는 바인딩 표현식을 정의합니다. 그리고 @onclick은 버튼을 누를 때 IncrementCount를 트리거하는 이벤트 콜백입니다.

이 Blazor 클라이언트 측 앱은 서버 백엔드와 어떻게 상호 작용할까요? FetchData.razor 페이지를 통해 알아보겠습니다.

@page "/fetchdata" 
@using BlazorClientServer.Shared 
@inject HttpClient Http
<h1>Weather forecast</h1>
<p>This component demonstrates fetching data from the server.</p>
@if (forecasts == null) 
{
  <p><em>Loading...</em></p>

} 
else 
{ 
  <table class="table">
    <thead>
      <tr>
        <th>Date</th>
        <th>Temp. (C)</th>  
        <th>Temp. (F)</th>
        <th>Summary</th>
      </tr>
    </thead>
<tbody>
        @foreach (var forecast in forecasts) 
        { 
            <tr>  
                  <td>@forecast.Date.ToShortDateString()</td>
                  <td>@forecast.TemperatureC</td> 
                  <td>@forecast.TemperatureF</td>
                  <td>@forecast.Summary</td>
            </tr>
        }
    </tbody>
} @code { 
    WeatherForecast[] forecasts; 
    protected override async Task OnInitializedAsync() 
    { 
      forecasts = await 
Http.GetJsonAsync<WeatherForecast[]>("WeatherForecast"); 
    } 
}

FetchData 페이지가 초기화되면 HTTP GET 요청을 통해 일기 예보 데이터를 비동기적으로 검색합니다. 일반적으로 JavaScript는 이 요구 사항을 AJAX 함수로 구현합니다. 여기서 이 역할은 Http.GetJsonAsync () 메소드에 의해 수행됩니다.

백엔드 애플리케이션 (BlazorClientServerApp.Server 프로젝트)은 그다지 많지 않습니다. localhost에서 서버 애플리케이션을 호스팅하고 일기 예보 기능을 위한 서버 엔드 포인트 구현을 제공합니다.

다음은 일기 예보 기능 자체인 WeatherForecastController.cs 입니다.

    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        //code block removed for the sake of brevity
        //...
        [HttpGet]
        public IEnumerable<WeatherForecast> Get()
        {
            var rng = new Random();
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }

마지막으로 WeatherForecast 클래스만 포함된 BlazorClientServerApp.Shared 프로젝트가 있습니다. 이것은 중요하지는 않지만 브라우저, WebAssembly 또는 서버의 전체 ASP.NET Core 애플리케이션 내에서 동일한 클래스를 실행할 수 있습니다.

Blazor는 서로 다른 .NET 구현 간에 공유되는 API 사양인 .NET Standard 2.0을 구현합니다. .NET 표준 클래스 라이브러리는 Blazor, .NET Framework, .NET Core, Xamarin 및 Mono를 포함한 다양한 플랫폼에 분산될 수 있습니다.

WeatherForecast 클래스는 매우 간단합니다.

  public class WeatherForecast 
  { 
      public DateTime Date { get; set; } 
      public int TemperatureC { get; set; } 
      public string Summary { get; set; } 
      public int TemperatureF => 32 + (int)(TemperatureC / 0.5556); 
  } 

Blazor 및 JavaScript 앱의 전망

이 포스팅에서는 Blazor와 WebAssembly 개념을 소개하고 이 프레임워크가 기존 JavaScript 및 ASP. NET 프로그래밍과 어떻게 다른지에 대해 설명했습니다.

또한, 동일한 애플리케이션이 클라이언트 측 호스팅을 사용하는지 아니면 서버 측 호스팅을 사용하는지에 따라 어떻게 다르게 작동하는지 확인하여 Blazor 클라이언트 측 접근 방식의 장단점을 더 잘 확인할 수 있었습니다.

마지막으로, Blazor 클라이언트-서버 앱 샘플의 다양한 부분을 살펴 보고 실제로 JavaScript 애플리케이션과 다른 부분을 확인하였습니다.

Blazor는 흥미로운 프레임워크이지만, 툴링 및 디버깅과 관련하여 개선해야 할 부분이 아직 많이 있습니다. JavaScript 프로그래밍은 여전히 많이 사용되며, 오래 지속될 것이지만, WebAssembly는 프론트엔드 개발자가 무시할 수 없는 기술입니다. Blazor는 .NET 전문가가새로운 언어를 배우지 않고도 풀 스택 개발자가 될 수 있는 훌륭한 기회입니다.