Asp.net Core에서 웹 UI를 만드는 데 레이저 페이지가 권장되는 이유는 무엇입니까?

Asp.net Core에서 웹 UI를 만드는 데 레이저 페이지가 권장되는 이유는 무엇입니까?

새로운 것을 배우는 것은 시간, 공간, 에너지의 투자를 필요로 합니다.저는 현재 Asp를 배우고 있습니다.Net Core MVC 2.0.이 ASP.NET Core 자습서 개요는 다음과 같습니다.

Razor Pages는 ASP.NET Core로 웹 UI를 만드는 데 권장되는 접근 방식입니다.

이 정보는 제가 Asp.net Core MVC 학습을 중단하고 Asp.net Core Razor Pages 학습을 시작해야 하는지 여부를 결정하는 데 있어 혼란스러웠습니다.

• Asp.net Core에서 웹 UI를 만드는 데 레이저 페이지가 권장되는 이유는 무엇입니까?

어떤 길이든지 환영합니다.

Microsoft 문서에 있는 이 기사에서:

MVC: 컨트롤러와 뷰를 사용하여 애플리케이션은 다양한 종속성과 뷰 모델을 사용하고 다양한 뷰를 반환하는 매우 큰 컨트롤러를 보유하는 것이 일반적이었습니다.이로 인해 많은 복잡성이 발생했고 종종 컨트롤러가 다음을 따르지 않는 결과를 낳았습니다.Single Responsibility Principle또는Open/Closed Principles효과적으로

Razor Pages는 웹 응용프로그램에서 주어진 논리적 "페이지"에 대한 서버 측 논리를 캡슐화하여 이 문제를 해결합니다.서버 측 논리가 없는 레이저 페이지는 단순히 레이저 파일(예: 레이저 파일)로 구성될 수 있습니다.“Index.cshtml”).그러나 대부분의 레이저 페이지에는 연결된 페이지 모델 클래스가 있으며, 관례에 따라 확장자가 ".cs"인 레이저 파일(예: "Index.cshtml.cs ")과 이름이 같습니다.이 페이지 모델 클래스는 컨트롤러 및 보기 모델의 책임을 결합합니다.컨트롤러 작업 방법으로 요청을 처리하는 대신 "OnGet()"과 같은 페이지 모델 처리기가 실행되어 기본적으로 관련 페이지가 렌더링됩니다.

레이저 페이지는 ASP.NET Core 앱에서 개별 페이지를 작성하는 프로세스를 단순화하는 동시에 ASP.NET Core MVC의 모든 아키텍처 기능을 제공합니다.새로운 페이지 기반 기능을 위한 좋은 기본 선택사항입니다.

MVC를 사용해야 하는 경우:

웹 API를 구축하는 경우 레이저 페이지를 사용하는 것보다 MVC 패턴이 더 합리적입니다.프로젝트가 웹 API 끝점만 표시하는 경우 웹 API 프로젝트 템플릿에서 시작하는 것이 이상적이지만 그렇지 않으면 컨트롤러 및 관련 API 끝점을 ASP.NET Core 앱에 쉽게 추가할 수 있습니다.또한 기존 응용프로그램을 ASP.NET MVC 5 이전 버전에서 ASP.NET Core MVC로 마이그레이션할 때 최소한의 노력으로 마이그레이션하려는 경우 보기 기반 MVC 접근방식을 사용해야 합니다.초기 마이그레이션을 수행한 후에는 새로운 기능에 레이저 페이지를 채택하는 것이 타당한지 아니면 전체 마이그레이션으로 채택하는 것이 타당한지 평가할 수 있습니다.

참고: Razor Pages 또는 MVC 보기를 사용하여 웹 앱을 구축할지 여부에 관계없이 앱은 유사한 성능을 가지며 종속성 주입, 필터, 모델 바인딩, 검증 등에 대한 지원을 포함합니다.

---

업데이트: 스콧 자우버가 언급한 이 깃허브 이슈에서 읽은 몇 가지 더 많은 이유:

저희는 [복합] 건강 보험 포털에 레이저 페이지를 사용하고 있습니다.우리는 60개 이상의 페이지를 가지고 있고 나는 서버 렌더링 HTML의 경우, 나는 결코 MVC로 돌아가지 않을 것이라고 말할 수 있습니다.그것은 또한 단순한 것들을 위한 것이 아닙니다.Health Insurance 도메인은 본질적으로 복잡하며 멀티 테넌트 애플리케이션(다른 보험 회사에 제품을 판매함)이라는 사실과 결합되어 보험 회사마다 작업을 조금씩 다르게 수행함에 따라 애플리케이션을 구성할 수 있기 때문에 더욱 복잡합니다.

왜 사용하나?

• 레이저 페이지는 기본적으로 더 안전합니다.위조 방지 기능을 제공하는 레이저 페이지기본적으로 토큰 유효성 검사입니다.또한 오버포스트 공격에 대한 노출을 제한하는 [BindProperty]를 통해 모델 바인딩할 속성을 선택할 수 있습니다.

• 레이저 페이지는 기본적으로 확장성이 더 우수한 폴더 구조를 가지고 있습니다.MVC에서 기본 폴더 구조는 단순히 확장되지 않습니다.Views, Controllers 및 종종 View Model에 대해 별도의 폴더를 사용하는 것은 세 가지 모두 궁극적으로 서로 긴밀하게 연결되어 있을 때 작업하기에 큰 PITA입니다.기능을 추가하거나 변경해야 할 때마다 세 개의 폴더 모두로 이동하고 여러 개의 폴더를 탐색할 수 있습니다.이것은 끔찍한 일입니다.이것이 제가 기능 폴더를 옹호한 이유입니다.레이저 페이지의 경우 페이지 모델(컨트롤러 + 보기)모델)이 View와 동일한 폴더에 있습니다.당신은 F7을 눌러 그것들 사이를 전환할 수도 있습니다.

• 확장성이 뛰어난 유지 관리 가능한 코드로 이어집니다.MVC를 사용하면 10개 이상의 작업으로 컨트롤러를 확대하는 것이 매우 쉬웠습니다.종종 이러한 작업은 서로 어떤 방식으로든 관련이 없습니다(두 작업 사이의 리디렉션 제외).이로 인해 코드를 찾기 위해 컨트롤러를 탐색하는 것이 매우 어려웠습니다.컨트롤러에도 개인적인 방법이 있으면 더 나빠졌고, 더 나아가 방법 블롯을 추가했습니다.레이저 페이지를 사용하면 페이지와 관련 없는 방법으로 페이지 모델을 확대하는 것이 거의 불가능합니다.페이지 모델에 있는 모든 내용은 페이지와 관련이 있습니다.

• 장치 테스트가 더 쉽습니다.컨트롤러를 사용하면 8개의 작업이 있을 수 있으며 주입하는 종속성 중 일부는 하나 또는 두 개의 작업에만 관련되어 있을 수 있습니다.따라서 유닛이 단일 액션을 테스트할 때 불필요하게 조롱하거나 둘 다 징그럽게 느껴지는 null을 통과해야 합니다(빌더 패턴으로 약간 해결할 수 있습니다).레이저 페이지의 경우 주입하는 종속성은 작업 중인 GET 및 POST 작업과 100% 관련이 있습니다.그냥 자연스러운 느낌이에요.

• 라우팅이 더 쉽습니다.기본적으로 레이저 페이지에서 라우팅은 폴더 구조와 일치합니다.이렇게 하면 폴더를 중첩하기가 훨씬 쉬워집니다.예를 들어, 모든 HR 관리 페이지는/Administrator 및 는 폴더및페아있습다니래에는지이직 ./Employee폴더를 누릅니다.여야만 체전 폴더권해관사다만다있의 수 ./Administrator관리자 기능을 구성하는 여러 컨트롤러를 사용하는 것보다 훨씬 쉬웠습니다.

저는 그게 중요하다고 생각합니다.

---

업데이트 2:

이것은 MVC 패턴의 복잡성에 관한 것으로, 질문에 직접적으로 답하지는 않지만 유용할 수 있습니다. Facebook의 엔지니어링 관리자는 "충분히" 큰 코드베이스와 대규모 조직에 대해 "MVC는 정말 빠르게 복잡해졌습니다."라고 말하며 MVC가 확장되지 않는다고 결론지었습니다.시스템의 복잡성은 코드를 "취약하고 예측할 수 없는" 새로운 기능을 추가하려고 시도할 때마다 기하급수적으로 증가했습니다.이것은 특정 코드베이스를 처음 접하는 개발자들에게 심각한 문제가 되고 있었습니다. 왜냐하면 그들은 무언가를 깰까봐 코드를 만지는 것을 두려워했기 때문입니다.결과적으로 MVC는 Facebook을 위해 무너졌습니다.

레이저 페이지는 페이지 기반 워크플로우에 최적화되어 있으며 기존 MVC 모델보다 이동 부품이 적은 이러한 시나리오에서 사용할 수 있습니다.이는 일반적으로 처리하는 것처럼 컨트롤러, 작업, 경로, 뷰 모델 및 뷰를 처리할 필요가 없기 때문입니다.대신 경로는 규약 기반이며 페이지 모델은 컨트롤러, 작업 및 보기 모델의 역할을 모두 수행합니다.물론 페이지가 보기를 대체합니다.또한 MVC만큼 폴더를 많이 보유할 필요가 없으므로 프로젝트가 더욱 단순해집니다.

ASP.NET Core - Razor Pages가 포함된 더 단순한 ASP.NET MVC 앱, 스티브 스미스의 2017년 9월 MSDN 기사:

[레이저 페이지] 제공

• ASP.NET Core 응용프로그램 내에서 코드를 구성하여 구현 로직을 유지하고 모델을 View 구현 코드에 가깝게 유지할 수 있습니다.
• 또한 ASP.NET Core 앱 개발을 시작할 수 있는 간단한 방법을 제공합니다.

이 문서에서는 페이지 기반 워크플로우에 MVC를 통해 레이저 페이지를 사용하는 이유에 대해 자세히 설명합니다.분명히, API의 경우에도 컨트롤러를 사용하고 싶을 것입니다.

타사 편집 - 기존 MVC 폴더 구성의 단점

ASP.NET Core - 2016년 9월의 오래된 MSDN 기사인 ASP.NET Core MVC를 위한 피쳐 슬라이스는 뷰와 컨트롤러를 구성하는 기존 MVC 규약이 더 큰 프로젝트에 불리한 이유를 설명합니다.이 문서에서는 느슨하게 관련된 네 가지 애플리케이션 개념의 예를 제공합니다.닌자, 식물, 해적 그리고 좀비.이 문서에서는 파일을 기능별 또는 담당 영역별로 폴더로 구성하여 기본 폴더 규칙 외부에 구성하는 방법에 대해 설명합니다.

Microsoft는 WebForms 접근 방식으로 돌아와 "Convention over configuration"이라는 구호를 신뢰하는 프로젝트 구조를 단순화하는 동시에 개발자에게 구성을 숨겨서 더 빠르게 작업을 수행할 수 있게 되었습니다.하지만 모든 것이 다시 섞일 것이라는 단점이 있습니다.그것은 조직화를 위한 현명한 조치처럼 보이지 않습니다.하지만... 이봐! 마이크로소프트에 대한 개발자들의 관심을 끌만한 새로운 것이 분명해요.

만약 당신의 페이지가 RESTful을 위해 MVC 웹 API를 사용한다면, 레이저 페이지를 사용하는 것이 정말 더 쉽습니다.그렇지 않다면 Core MVC를 사용하는 것을 추천합니다.

모델과 컨트롤러가 동일한 파일에 함께 있는 대규모 프로젝트에서는 유지보수가 악몽이 될 것입니다.속성이 2개뿐인 클래스에 적합하지만 OOP의 Open Close 원칙을 위반합니다.시간에 따라 확장할 수 있는(확장 가능) 아키텍처를 설계하고 사용해야 하며, 여전히 안정적이고 논리적이어야 합니다(프로젝트 재구성 없음). 동일한 패턴을 사용하여 확장하기만 하면 됩니다.

소프트웨어 설계자로서 저는 디자인 패턴을 자동으로 사용합니다.제가 가장 좋아하는 것은 파사드 디자인 패턴입니다.홈 컨트롤러 뒤에 홈과 관련된 모든 내용을 숨기고 리포지토리에서도 동일한 작업을 수행할 수 있습니다.

재밌는 거 알고 싶어요?한 여행 가이드가 파사드라는 이름이 어디서 유래했는지 설명했습니다.암스테르담에는 바다 건너에 큰 집들이 있습니다.밖에서 보면 그들은 고급스러워 보입니다.하지만 뒤에서 보면 지저분해질 수 있습니다.그 집의 외관은 그 뒤에 무엇을 숨기고 있습니다.디자인 패턴은 건축계에서 나옵니다.글쎄요, 제 지원서 뒤에 있는 것들도 좋아 보이지만 여행 가이드에게 설명을 들을 수 있어서 좋았습니다.

레이저 페이지의 공유 및 그룹화 작업에 대한 지원은 어떻습니까?MVC 컨트롤러를 보면 기능에 따라 컨트롤러 작업을 그룹화할 수 있음을 알 수 있습니다.홈 페이지는 이러한 기능이라고 할 수 있습니다.그런 다음 정보()와 연락처()가 들어 있는 홈 컨트롤러가 있지만 레이저 페이지의 경우 페이지가 다릅니다.5개의 다른 보기가 포함된 큰 홈 컨트롤러가 있을 수 있습니다.이들은 모두 동일한 홈 컨트롤러에서 그룹화할 수 있습니다.

컨트롤러에는 레이저 페이지에는 없는 두 가지가 있습니다.

1. 공유:다른 페이지 간에 컨트롤러 작업을 공유할 수 있으며, 때때로 컨트롤러 작업이 한 페이지에만 바인딩되지 않고 여러 페이지 간에 공유될 수 있습니다.컨트롤러 작업은 데이터(JSON/XML/ 등)만 반환할 수 있습니다.때때로 그들이 반환하는 것은 다른 페이지에서도 사용될 수 있습니다.
2. 그룹화:관련 컨트롤러 작업을 하나의 컨트롤러에서 함께 그룹화할 수 있습니다.알겠습니다. 작은 컨트롤러 파일의 팬이라면 이렇게 하지 않을 것입니다.그렇습니다. 기능에 따라 컨트롤러를 그룹화합니다.그렇게 하면 훨씬 쉽게 탐색할 수 있습니다.

레이저 페이지에서는 어떤 방법으로 이 문제를 처리할 수 있습니까?디렉토리 사용:

• 그룹화:홈 컨트롤러가 있으면 모든 홈 페이지가 포함된 하위 디렉토리 홈을 만들 수 있습니다.

질문:간단한 집이라면 그것으로 충분할 것입니다.그러나 모든 작업에 동일한 리포지토리를 사용하는 XController가 있다고 가정해 보겠습니다.XController의 Initializer 기능에서 해당 Repository를 초기화할 수 있습니다.그러나 X 하위 디렉터리에 있는 페이지의 경우 모든 X 작업에 대해 이 작업을 다시 수행해야 합니다.그거 드라이야?

• 공유:"공유" 하위 디렉토리를 만들고 그 아래에 페이지 간에 공유되어야 하는 기능을 가진 디렉토리를 만들 수 있습니다.

질문:제 수정 사항을 보시면 제가 디렉토리를 사용하여 레이저 페이지의 공유 및 그룹화 문제를 해결하는 것을 볼 수 있습니다.

어떻게 하시겠습니까?

아니면... 레이저 페이지는 단순한 웹 사이트를 위한 것입니까? 이것이 이 버전의 레이저 페이지에 대한 결론일 수 있습니다.

Blazor 서버에 이상한 아키텍처가 있습니다.이것은 SignalR을 사용한 채팅 애플리케이션처럼 보입니다.그런 애플리케이션에 대한 제 경험은 이벤트가 손실될 수 있다는 것입니다.저는 이벤트를 잃고 싶지 않습니다. 더 좋은 것은 이벤트가 쌓여 있고 우편처럼 처리되도록 보장하는 것입니다.

개발자들은 2013년 포럼에서 "Microsoft가 무엇을 의미하는지, Silverlight는 권장되지 않습니다.이번에만 MVC가 데드와 롱 라이브 MVVM으로 선언됩니다.그리고 MVC가 천천히 폐기물 더미로 던져질 것이라고 예상할 수 있지만, 지금으로부터 약 18개월 후에 속도가 빨라질 것입니다. 그리고 MVC를 배우는데 소비한 모든 시간은 같은 폐기물 더미로 가게 될 것입니다.또한 MVVM은 쉬워 보이지만 실제로 제대로 작동하려면 1년이 걸립니다.

언급URL : https://stackoverflow.com/questions/46777404/why-is-razor-pages-the-recommended-approach-to-create-a-web-ui-in-asp-net-core