이번에 asp.net을 이용하여 웹페이지를 제작하려 합니다.
그런데 계획 중 asp.net mvc와 asp.net core의 방식 중 어떤 방식을 이용해야 할지 고민이 큽니다.
mes프로그램을 운용하는 회사는 어떤 방식을 더 선호하는지 궁금합니다.
또한 mes에 국한되지 않고 c#으로 웹 개발을 할 경우 더 많이 사용하고 앞으로 더 많이 사용될 것 같은 방식도 추천해주시면 감사하겠습니다.
2개의 좋아요
이제 통합된 .net 7.0 을 하시면 고민 해결 되실듯 싶은데
이게 신규 프로젝트 일 경우에는 큰문제가 없는데
아마도 regacy 가 vb .net 2.0 3.0 중구 난방이라
호환 안되실 수 있는데 당장은 힘들어도 .net 5이상으로 가보시길 권합니다.
이제 core는 잊으세요 통합됬습니다 ^^
3개의 좋아요
개발팀 내 인력 현황이나 포트폴리오에 따라 답이 달라지는 부분, 장기적인 관점에서의 선택에 따라 달라지는 부분이 둘 다 고려가 되어야 할 것 같습니다.
새로운 애플리케이션 프로젝트를 진행해야 하는데, 팀 내 개발 인력이 .NET Framework 기반의 기술 만 치중해서 써야 하는 상황이라면, 불가피하게 IIS/ASP.NET 조합으로 새 애플리케이션을 만들어야 할 수 있습니다.
하지만, 새로운 애플리케이션 프로젝트를 만드실 예정이라면, 기본적으로 새로운 .NET (편의상 .NET Core 계열이라고도 부릅니다.) 기반으로 애플리케이션을 만드는 것이 좋습니다.
참고로 양쪽 모두 ASP.NET MVC는 존재하지만, 편의 상 .NET 쪽에 붙는 MVC는 ASP .NET MVC Core 라고 분리해서 부릅니다.
2개의 좋아요
죄송합니다 제가 잘 몰라서 이상한 질문을 하게되었습니다.
2개의 좋아요
이상하지 않아요! 햇갈릴 수 있을만한 부분이고, 그것을 확인하려는 질문입니다. 미안해 하지 말아주세요. 
4개의 좋아요
제가 궁금하였던 부분은 스프링으로 웹을 제작할 당시에는 .net의 mvc방식처럼 view의 코드를 controller와 하나로 묶지 않았어서 궁금하였었습니다. .net으로 웹을 제작하게 된다면 view를 controller와 함께 작성하는게 일반적인 경우인지 또한 최근의 방식들도 그런것인지가 궁금하였습니다.
2개의 좋아요
아마도 언급하신 내용은 webform 방식이신것 같고
Visual studio로 mvc 프로젝트를 생성하시면 기본 템플릿부터
View Controller Model
분리해서 생성합니다.
4개의 좋아요
현재 닷넷의 웹앱 개발 프레임워크는 아래와 같이 구분됩니다.
-
Asp.Net Core MVC
전통적인 MVC 구조로, 라우팅의 기준점은 콘트롤러 클래스(의 이름)입니다.
컨트롤러와 뷰 파일을 별도로 작성합니다. -
Asp.Net Core Web Application
라우팅의 기준점은 (웹) Page 클래스(의 폴더)입니다.
Page는 MVVM 구조의 뷰 파일입니다.
즉, 이 프레임워크에서는 뷰파일만 작성합니다. -
Asp.Net Core Blazor
이 프레임워크도 뷰 파일만 작성하는데, 뷰를 페이지가 아닌, 콤포넌트로 봅니다.
콤포넌트는 라우팅 정보를 포함하면, (웹) 페이지처럼 요청을 처리할 할 수 있고, 없다면, 일반 콘트롤(버튼, 리스트, 라벨 등)처럼 사용이 가능합니다.
블레이저가 웹페이지와 다른 점은 Single Page Application(SPA) 기반이라는 점입니다.
(페이지 전환마다 요청이 발생하지 않습니다)
여기에는 두 가지 모델이 있는데,
3-1. Blazor Web Assembly
작성된 웹앱은 웹어셈블리로 빌드됩니다.
사용자가 최초 접속 시, 빌드된 웹어셈블리가 클라이언트의 브라우저에 다운로드되고, 브라우저에서 실행됩니다.
빌드된 웹 어셈블리는 일종 static 파일이기 때문에, 정적인 서버에서도 운용이 가능하고, 클라이언트에게 다운로드되면 서버와 연결 없이 독립적으로 실행됩니다.
실행 파일이 클라이언트에게 통으로 넘어 가기 때문에 최초 접속 시 로딩 시간이 긴 편이고, 코드 보안에 취약합니다.
3-2 Blazor Server
서버가 콤포넌트(렌더 트리)만 브라우저에게 전달합니다.
전달된 콤포넌트는 SignalR 이라는 통신 수단으로 서버와 통신하여 데이터(DOM)를 업데이트합니다.
구조가 그렇다는 것이지, 개발자가 SignalR 과 관련한 처리를 할 일은 없습니다.
컴포넌트(뷰)만 클라이언트에게 넘어가기 때문에, 웹 어셈블리 보다는 로딩 속도가 빠르나, 여기에는 Signal과 관련한 요소들이 포함되기 때문에, MVC/웹페이지 보다는 최초 로딩 시간이 약간 긴 편입니다.
그런데, 최초 로딩 이후에는 일반적인 Http Request/Response 과정 보다 빠른 SignalR을 사용하기 때문에 응답 속도가 매우 빠르고, 데이터 량도 훨씬 적습니다.
물론, 웹 어셈블리는 SignalR 조차 사용하지 않고, 브라우저 내부에서 실행되기 때문에, 응답 속도가 가장 빠릅니다.
참고로, 현재 닷넷은 블레이저를 밀고 있는 듯 보입니다.
닷넷의 전통적인 UI 앱(Asp.Net, 윈폼, WPF, Xamarin, MAUI 등) 프레임워크는 자신만의 콘트롤 체계를 보유하는데, 이들은 서로 호환되지 않거나, 매우 제한적으로 호환됩니다.
이들을 html 태그 기반의 컴포넌트로 통합하기 위한 기반 기술이 블레이저입니다.
블레이저 컴포넌트를 웹앱과 데스크탑앱, 모바일 앱에 모두 사용할 수 있는 제반 환경이 모두 갖춰져 있어, UI 중복 작성을 최소화합니다.
즉, 웹페이지, 데스크탑 앱, 모바일 앱에서 작성한 블레이저 컴포넌트를 수정 없이 바로 다른 앱에서 사용할 수 있게 된 것이죠.
그리고, 블레이저의 미래는 PWA(Progressive Web Application)가 될 것 같습니다.
이 기술에서는 사용자가 웹 서버의 기능이 맘에 드는 경우, 그 앱을 자신의 컴퓨터에 바로 설치할 수 있습니다. 설치하고 나면, 그 웹 서버에 다시 접속할 필요 없이 로컬에서 바로 실행됩니다.
이러한 흐름을 간략하게 표현하면, 닷넷은
- 닷넷 코어로 전환하면서, 크로스 플랫폼 기반을 갖췄고,
- 블레이저로 UI 도구 통합을, 그리고,
- PWA 로 앱 배포 방식의 통합까지 하려고 하는 것 같습니다.
블레이저의 경우, 저 같이 콘트롤만 사용하던 사람에게는 매우 불편한데, CSS 대한 이해도가 높다면 아무런 문제가 없을 것입니다. (javascript 기술은 거의 필요하지 않습니다)
11개의 좋아요
자세한 답변 감사합니다. 덕분에 .net에 대해 더 이해하게 되었습니다.
3개의 좋아요