asp.net 웹 개발 기술을 어떻게 보시나요?

asp.net의 지난 10년을 간략하게 검토해 보겠습니다.

mvc가 인기를 끌기 전

ASP.net의 서버 측 컨트롤은 html과 js를 함께 캡슐화합니다. 다수 클라이언트 이벤트는 생성된 js를 통해 자동으로 데이터를 서버에 다시 게시합니다. 많은 초보자의 경우 컨트롤을 드래그 앤 드롭하고 C# 코드를 작성하는 것만으로도 사용 가능한 웹 프로젝트를 구현할 수 있으므로 진입 장벽이 크게 낮아집니다. 그에 따라 서버 측 컨트롤의 과도하게 결합된 디자인은 많은 단점을 가져왔습니다. 즉, 컨트롤을 사용자 지정하기 어렵고 프런트 엔드와 백 엔드를 순수하게 분리하기가 어렵기 때문에 ASP.NET 실무자는 둘 다 할 수 없습니다. 프론트엔드 기술에 능숙하지 않고 더 많은 백엔드 기술(생태학적 문제)에 손을 대지 않습니다.

이 시대에 .net은 "드래그 앤 드롭 제어"로 분류됩니다.

mvc가 인기를 얻은 후

Microsoft는 asp.netmvc를 출시했으며 많은 회사에서 프런트엔드와 백엔드를 분리하려고 시도하기 시작했습니다. 모델에 관한 한, 다른 언어 플랫폼의 MVC 기반 웹 프로젝트 개발 모델과 다르지 않습니다.

그러나 asp.net의 서비스 프레임워크 자체가 너무 복잡하고 특히 어렵습니다(주의를 기울였다면 asyncawait 비동기 프로그래밍을 지원하고 나면 어렵다고 말할 수도 있습니다). , 동기화 컨텍스트 모델에는 너무 많은 단점이 있습니다. 첫째, 소스 코드 구조가 혼란스럽고, 둘째, 비동기 메서드를 부적절하게 사용하면 요청으로 인해 예외가 발생하기 쉽습니다. 반환되고 컨텍스트가 해제된 다음 동기화 개체를 찾을 수 없습니다. 문제의 근본 원인은 대부분의 프로그래머가 스레드에 대해 깊이 이해하지 못한다는 것입니다. 프로젝트에 올바르게 표준화된 사용법이 있어도 괜찮습니다. 그렇지 않으면 많은 사람들이 예외가 발생할 때 문제가 어디에 있는지 알지 못할 것입니다. Blog Park를 개조하는 동안 교착 상태가 발생했습니다. 관심이 있으시면 Blog Park 공식 블로그에서 작성한 내용을 읽어보세요.

aspnetcore

저는 새로운 애플리케이션 모델 디자인과 코드 구현을 매우 좋아합니다. 다른 것은 말할 것도 없고 간단한 Reqeust 및 Response 개체를 살펴보십시오. 미들웨어 파이프라인을 다시 살펴보면 컨텍스트가 위임 체인을 통해 계속 전달되므로 모호한 동기화 컨텍스트에 대한 필요성이 제거되고 Windows 보안과 관련된 기능이 제거됩니다.

전체 구조가 더 명확해지고 확장을 좋아하는 사람들은 하루에 장안 꽃을 모두 볼 수 있는 즐거움을 누릴 수 있을 것입니다.

물론 자연스러운 성능은 물론 마이크로소프트가 이전에 github에서 했던 mvc 이외의 성능 테스트 비교도 주목해 볼 수 있습니다.

NET 생태학

오픈 소스를 수용한 후 netcore, 표준, aspnetcore, efcore 등과 같은 일련의 구현을 모두 사용할 수 있으며 내년 netcore3.0에도 클라이언트가 포함될 예정입니다. 모델(wpf 및 winform은 Windows에서만 사용할 수 있음)

github의 aspnet, dotnet, dotnet-architecture 및 기타 분기에는 Microsoft에서 직접 유지 관리하는 수많은 오픈 소스 프로젝트가 포함되어 있습니다.

오픈 소스 커뮤니티의 대부분의 프로젝트는 표준 표준을 기반으로 타사 구성 요소를 따르고 패키징했습니다.

Microsoft는 오랜만에 docs 하위 도메인에 흩어져 있는 문서를 수집했습니다.

모든 것이 스크립트로 작성되었지만 생태성이 부족합니다. Apache Foundation의 중요한 프로젝트에 .net 브랜치가 있다면 netcore에 의존하면 다시 많은 점유율을 확보할 수 있을 것이라고 믿습니다.

전망

마이크로서비스가 대중화된 후에는 실제로 여러 플랫폼을 혼합하여 내부적으로 서비스를 제공하는 것이 가능합니다. -party 구성 요소는 Microsoft의 일관된 스타일과 개발 효율성을 기반으로 매우 높습니다.

사실 현재 많은 내부 시스템에서 .net을 사용하고 있지만, 이는 풍부한 타사 리소스가 필요한 인터넷 관련 프로젝트에만 사용되며 .net을 사용하는 경우는 상대적으로 적습니다. 그러나 많은 대기업에는 .net 지점 팀이 있습니다. 결국 데스크탑과 개발 효율성의 이점은 여전히 ​​가치가 있습니다.

ASPNET은 어떻게 발전할 것인가? 개인적으로 커뮤니티의 반응과 생태계가 점차 풍요로워질 수 있을지에 달려있습니다.

마이크로소프트의 노고를 보면서 개인적으로는 다시 돌아올 수 있기를 바란다.

그럼요?

장기적인 관점에서 보면 플랫폼은 우리의 도구일 뿐입니다. IT 담당자는 자신의 기술 범위를 특정 플랫폼으로 제한해서는 안 됩니다. 더 많이 배우고 더 많이 축적하세요. 실제 프로젝트에서는 요구사항, 아키텍처, 팀을 기준으로 선택해야 합니다.

예를 들어 Java와 .net은 동시에 마스터할 수 있으며, 각각의 장점을 활용할 수 있어 서로 겹치는 부분이 많아 학습 비용이 높지 않습니다. 게다가 대부분의 지식은 플랫폼과 아무런 관련이 없습니다.

개인적인 의견은 순전히 손으로 쓴 댓글이나 의견을 환영합니다.