ASP.NET MVC에서 ASP.NET CORE MVC + WEBAPI의 여정 - 파트2

이제 MVC 대신 BLAZOR SPA를 할 차례 입니다.

 

.NET을 사용하는 Web project들은 대부분 MVC로 구현된다.

 

또는 현대적 어플리케이션을 작성한다면 대부분 react, vue를 사용하고 있으리라.

(angular는 사랑받지 못하고 있다...)

 

그럼 왜 Blazor를 추천하는가?

 

파트1에서 대부분의 개발자가 Winform을 거쳐왔다고 이야기 하였다.

 

그러나, 특이 케이스들이 있으니, WPF, Sliverlight를 개발해본 개발자들이 되겠다.

 

WPF는 간단히 말해서 마크업 기반으로 UI 프로그램을 작성할 수 있는 UI프레임워크가 되겠다.

 

그렇다, WPF 마크업이 HTML의 마크업과 유사(?)하기에, 또한 MVC를 거치며 모델화하는 프로젝트를 경험한 개발자에게 유용한 Blazor는 .net 개발자들에게 WPF 느낌의 웹 UI 프레임워크인 것이다.

 

Blazor는 기본적으로 양방향 바인딩을 지원한다.

또한 상태관리, 즉, 하위 데이터 변경에 대한 상위 전달에 있어 매우 쉽게 진행할 수 있다.

사실, Vue와 Angular에 가깝다고 볼 수 있다.

 

그렇다면 왜 react는 대상이 아니냐면, 상태관리에 대한 props를 핸들링하는 것은 매우 귀찮고 작성해야 할 코드가 많아지기 때문이다.

 

또한 Blazor는 상속개념을 통해서 UI Component를 작성할 수 있다.

 

BaseComponent라는 것을 작성하고 기본 UI에 대한 동작을 정의한 후 페이지에 대한 Component를 상속받아 이벤트 로직만 작성하게 할 수 있다.

 

따라서 페이지 기반으로 작성해야 하는 react, vue에 비하여 반복적인 작업을 줄이고 공통화를 할 수 있다.

이점에서 angular와 가깝다고 볼 수 있다.

 

특이한 점은 OOP 페러다임이 점차 줄어들면서 사실상 웹 개발, 즉, node를 사용하는 front, backend는 상속이란 부분을 매우 느슨하게 보고 있다는 점이 아쉽다.

 

물론 복잡한 중첩 상속을 피하는 것이 권장사항이기는 하지만 본래 모든 프로그래밍은 상속 구조 없이는 극단적 코드수 줄이기에 적합하지 않기 때문이다.

 

여튼, 그렇다면 Blazor는 어떤 작업에 유리할까?

아래와 같다.

 

1. 커머스, 홈페이지, 일반 불특정 다수를 상대하는 사이트 : Blazor Server, Blazor App(Server + SPA)

2. 관리자형 사이트 : Blazor SPA

3. 웹앱 : MAUI + Blazor SPA

 

한가지 주의할 점은 Blazor SPA는 처음 로딩 속도가 문제라는 것이다.

확실히 js 세계의 framework들 보다 느리다. 하지만 지금은 많이 개선 되어서 적어도 0.5~1초 내외로 로딩되게 되었다.

신규 프로젝트이고 관리자 형 사이트라면 Ant Design of Blazor (antblazor.com) 를 추천한다.

관리자 사이트용 Control들이 많고 AntDesign JS 기반이라 프로젝트가 중단될 여지도 별로 없다.

관리자형 사이트 개발에 매우 유용하다.

 

Blazor App은 정확히 next.js와 일치한다.

첫 페이지 호출시 SSR로 실행되고 이후에 CSR로 정의된 Comopnent들은 첫 페이지 SSR요청시 백그라운드로 다운로드 받게 된다.

따라서 Blazor Server와 Blazor SPA가 결합된 것을 의미하므로, 서로의 약점을 보완하는 최종 결과물인 셈이다.

(Blazor Server는 첫 페이지 로딩이 없고, SPA는 Server기반 UI 통신이 없으므로 오프라인에 대한 이슈가 없는 셈이다.)

 

이제 WEB API를 알아보자.

 

WEB API는 MVC 프로젝트와 동일하게 볼 수 있다.

다만, .net core +에서는 명시적으로 MVC Controller와 API Controller가 분리된다.

 

Front를 SPA로 작성하기로 결정했다면 Backend는 API로 처리하면 된다.

 

파트1에서 설명한대로 로그인 및 인증은 해당 프레임워크가 지원하는 JWT를 사용하도록 하자.

물론, 권한과 역활 관련해서 bit연산을 좋아하는 개발자라면 별도의 Auth Attribute또는 Middleware를 만들어야 할 것이다.

 

권장할 만한 사항은 BaseController를 만들고 시작하라는 것이다.

일부 의존성 주입이나 인증과 관련된, 또는 계정 정보와 관련된 사항을 구현해 놓고 시작한다면 좋은 스타트라고 볼 수 있다.

 

또한, 아무리 급하더라도 Controller Method에 때려 넣는 방식의 개발은 하지 말자.

.net core +에서는 의존성 주입을 기본적으로 제공하므로 적어도 Service레이어(프로젝트) 정도는 만들어 주는 것이 예의다.

의존성 주입을 자동화하고 싶다면 Scrutor 를 추천한다.

한번 살펴보자.

 

위에 열거된 사항을 필자는 공개 레포에 구현하고 있다.

nameofSEOKWONHONG/Jina.Application: Jina passion Application (github.com)

GitHub - nameofSEOKWONHONG/Jina.Application: Jina passion Application

참고가 필요하다면 해당 소스를 분석해 보자.