최근 웹 개발은 MVC를 빼놓고선 더 이상 말할 것이 없을 정도로 MVC가 일반화되어 있다.


Model - View - Controller


개념은 참 좋...을 뻔 했으나, ASP.NET 환경에서는 내가 보기엔 그냥 말 장난이다.


Model은 Class reference 이상도 이하도 아니고,

View는 Page UI 그대로이며,

Controller는 기본적으로 Code behind와 전혀 다를 바 없다. 


적어도 ASP.NET 웹 개발환경에서는 별 특별한 점이 없는 동일한 것이었다. 원래는.


그런데 그게 못마땅했을까, 언젠가부터 무리수가 시작되기 시작했다.


그 무리수들에 대해 오래 전부터 쓰고 싶었지만 대세가 아닌 듯 하여 아꼈던 생각을 한번 써 본다.

다시 한번 말하지만, 대세가 아닌 소수 의견이니 따라하면 손해보기 십상이므로 주의할 것. ㅎㅎ




Code behind 기반의 ASP.NET에서는 원래 Page UI에서도 쉽게 서버 코드를 작성할 수 있다.

즉, cs 파일에 별도로 서버 코드를 작성하지 않고 aspx 파일에 서버 코드를 바로 쓸 수 있다.

당연하게도, Code behind의 출발이 Page UI에 통합/혼재되어 있던 코드를 

서버/클라이언트 코드로 분리하여 가독성과 유지보수를 용이하게 하기 위함이었으니 말이다.

(ASP가 ASP.NET으로 넘어가면서 바뀐 가장 큰 외형적 변화가 바로 서버/클라이언트 코드의 분리다.)


그런데, MVC에서는 View가 Code Behind격인 Controller와 구조적으로 멀리 떨어지게 되는 바람에

쉽게 서버/클라이언트 코드를 오가며 작성 또는 리뷰하는 것이 어려워지게 되었다.

(물론 IDE의 "정의로 이동", "참조로 이동" 같은 기능을 이용하면 그리 어렵지 않게 볼 수 있긴 하다.)


그래서 편의성이라는 미명하에(사실은 궁여지책으로) 고안해 낸 View DataHTML Helper라는 

괴기/변태스런 자체 내부 확장 라이브러리(API)들부터 시작해서,

급기야 MVC 3 버전 이상으로 넘어가면서부터는 razor라는, 

완전 시대를 역행하는 웃기는 코드까지 만들어지게 됐다. cshtml 파일이라니. 헐...

(MVC 3때 갑툭튀 나온 razor를 보고, 얼마 못 가서 사라질 줄 알았었다, 한 때는...)


razor가 왜 시대를 역행하는 코드냐면,

한 마디로 하면 그냥 초창기 ASP 코드 이상도 이하도 아니기 때문이다.

@만 붙이면 서버/클라이언트 코드를 완전 뒤죽박죽으로 섞어서 만들 수 있는 코드...

ASP.NET이 왜 높은 생산성으로 각광받게 됐는지 전혀 이해하지 못한 덜떨어진 방식이다.

(물론 PHP나 JSP 등 원래 그런 방식뿐인 다른 개발 언어로 웹 개발을 하다 넘어온 사람이나, 

서버/클라이언트 오가며 개발하기 귀찮아 하는 입장에서는 더 편하다 느낄 수도 있다.

또, 요즘은 Javascript 라이브러리 춘추전국시대라 할 만큼 스크립트 위주의 개발 시대라서 더욱...)


razor 코드만 시대 착오적인 무리수인 것이 아니다.

이 razor 코드를 사용하는 ASP.NET MVC를 구성하는 기반 형식이 바로 var와 dynamic인데,

var와 dynamic 형식은... Javascript같은 느슨하고 유연한 언어에 익숙한 사람들은 좋아할 수도 있겠지만

어지간해서는 var조차 쓰지 않으려고 노력하는 나로서는 C#을 가장 ㅈ같이 만든 나쁜 두 가지 예로 본다.

컴퓨터 언어란 모름지기 0이면 0이고 1이면 1이어야 하거늘... 이게 웬 무리수란 말인가?

async...await 구문도 개발자의 thread 개념을 말아먹게 만드는 어처구니없는 뻘코드지만

var와 dynamic은 정말이지... 코딩의 기초 개념조차 말아먹게 만드는 개뻘코드다.


또 하나 쥐약같은 것은,

REST 호출 방식의 MVC를 유지하려다 보니 생성자 의존성 주입(DI; Dependency injection)이라는,

이전까지는 해킹업계에서나 다루던, 참으로 어처구니 없는 Injection 개념까지 도입해야 했다.

REST 호출로는 생성자를 따로 만들고 해당 생성자를 호출할 정상적인 방법이 없었으니까 말이다.

(이게 무슨 말인지 개념을 잘 모르겠으면... 아래 사이트 참고.)


>> 참고1: https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/dependency-injection

>> 참고2: https://blog.agilistic.nl/a-step-by-step-guide-to-using-ninject-for-dependancy-injection-in-c-sharp/



DI에 비하면 ModelBinder나 ActionFilter는 애교로 봐줄 정도...

그러다 보니, 그런 불필요해야 마땅하지만 필요해져 버린 기능들을 구현해 놓은 라이브러리들, 

예를 들면 OWIN이라든가, Unity, Ninject 등등이 하나 둘 만들어지기 시작했고,

그런 라이브러리들이 하나 둘 Visual Studio 기본 생성 코드로 들어가거나 필수적으로 사용됨에 따라 

ASP.NET 자체가 갈수록 복잡해지기 시작했다. 헐...

(Visual Studio에서 새 MVC 웹 사이트 하나 만들어 보면 무슨 말인지 바로 알 수 있다.)


요즘 ASP.NET 웹 사이트 하나 만들려면 EntityFramework, log4net, OWIN, razor는 기본이고,

필요에 따라 또 newtonsoft 등 여러가지 라이브러리들을 nuget을 통해 막 갖다 붙여야 하는 시대가 되었다.

작성해야 할 소스 코드의 양은 줄었지만 참조 라이브러리나 관련 환경설정은 엄청나게 많고 복잡해졌다.


한 줄로 표현하자면,

쉽게 사용할 수 있게 하기 위해 만들어진 라이브러리들 때문에 되레 어렵고 복잡해진 개발이 된 셈.

이게 말이 되나? 대체?


아 물론, 각 라이브러리들 하나 하나 따로 보면 없는 것보다 있는 것이 훨씬 낫고 쉽고 편해졌겠지.

또, 그 모든 걸 다 배우고 익히고 이해한 후에 익숙하게 사용할 수준이 되고 나면, 당연히 편하겠지.

그런데 그렇지 못한 사람들은 라이브러리 사용법 익히다 볼 일 다 볼 수준이니... 이게 과연 정상일까? 


대략 난감에 암담함이다... 




이젠 개발이라는 것이 라이브러리 검색 및 조합 기술이 돼 버렸다.

이젠 ASP.NET도 Java와 비슷하게 C#과 ASP.NET만 알아서는 웹 사이트 하나 못 만든다.

(Java로도 lombok이니 mybatis니 thymeleaf 등등을 다 알아야 웹 사이트를 만들 수 있다.)


아니, 더 정확하게 말하면, C#과 ASP.NET만 알아도 웹 사이트는 충분히 만들 수 있지만

저런 라이브러리들로 도배된, 남이 만든 웹 사이트는 전혀 이해할 수가 없다.

이게 21세기 개발의 방향으로 맞는 방향인걸까?


그렇다면,

뭐 이젠 내가 시대에 뒤처진 꼰대가 된 거겠지.





Posted by 떼르미
,


자바스크립트를 허용해주세요!
Please Enable JavaScript![ Enable JavaScript ]