웹 API를 사용하는 순수 프론트 엔드 JavaScript 및 Ajax를 사용한 MVC보기

이것은 요즘 웹 애플리케이션을 분할하는 방법에 대한 사람들의 생각에 대한 토론이었습니다.

모든 뷰와 컨트롤러로 MVC 응용 프로그램을 만드는 데 익숙합니다. 직접 채우고 싶지 않은 특정 영역이없고 DOM 페이지로드 이벤트를 사용하여 서버를 호출하여 다른 영역을로드하지 않는 한, 전체보기를 작성하고이를 전체 페이지 요청에서 브라우저로 다시 전달합니다. AJAX를 사용하여.

또한 부분 페이지를 새로 고칠 때 MVC 작업 메서드를 호출하여 HTML 부분을 반환하여 페이지의 일부를 채우는 데 사용할 수 있습니다. 초기 페이지로드 속도를 늦추고 싶지 않은 영역 또는 AJAX 호출에 더 적합한 영역에 해당됩니다. 한 가지 예는 테이블 페이징입니다. 다음 페이지로 넘어가려면 AJAX 호출이 전체 페이지 새로 고침을 사용하지 않고 해당 정보를 얻은 경우 선호합니다. 그러나 AJAX 호출은 여전히 ​​HTML 조각을 반환합니다.

내 질문은 순수한 프론트 엔드 배경이 아닌 .net 배경에서 왔기 때문에이 구식에 대한 생각이 있습니까?

내가 함께 일하는 지능형 프론트 엔드 개발자는 MVC 관점에서 거의 아무것도하지 않는 것을 선호하며 오히려 프론트 엔드에서 모든 것을 할 것입니다. 페이지를 채우는 웹 API 호출까지. 따라서 HTML을 반환하는 MVC 작업 메서드를 호출하는 대신 표준 개체를 반환하고 javascript를 사용하여 페이지의 모든 요소를 ​​만드는 것을 선호합니다.

프론트 엔드 개발자 방식은 클라이언트 측 유효성 검사를 포함하여 MVC 모델 유효성 검사에서 일반적으로 얻는 모든 이점이 사라진다는 것을 의미합니다. 또한 강력한 형식의 html 템플릿 등으로 뷰를 만들면 얻을 수있는 이점이 사라질 것입니다.

이것이 프런트 엔드 및 백 엔드 유효성 검사에 대해 동일한 유효성 검사를 작성해야 함을 의미한다고 생각합니다. 자바 스크립트는 DOM의 모든 다른 부분을 생성하기위한 많은 메소드를 가지고 있어야합니다. 예를 들어, 테이블에 새 행을 추가 할 때 일반적으로 MVC 부분보기를 사용하여 행을 만든 다음이를 AJAX 호출의 일부로 반환하면 테이블에 주입됩니다. 순수한 프론트 엔드 방식을 사용하면 자바 스크립트는 API 호출에서 행에 대한 객체 (예 : 제품)를 가져 와서 해당 객체에서 행을 만듭니다. 테이블 행의 각 개별 부분 작성

문제의 웹 사이트에는 관리, 양식, 제품 검색 등 다양한 영역이 있습니다. 생각하지 않는 웹 사이트는 단일 페이지 응용 프로그램 방식으로 설계해야합니다.

이것에 대한 모든 사람들의 생각은 무엇입니까?

프론트 엔드 개발자와 백엔드 개발자의 의견을 듣고 싶습니다.

또한 모든 새로운 웹 앱이 SPA 여야한다는 점에 대해서는 다소 회의적이지만 클라이언트 측에서 많은 경험을 가진 일반인으로 100 % 판매되는 것은 익지 않은 서비스 지향 아키텍처입니다. 클라이언트에서 HTML이 아닌 데이터는 서버에서 미리 작성된 페이지 / 뷰를로드하고 페이지로드 후 데이터로 많은 동적 작업을 수행하거나 JavaScript를 사용하여 거의 100 % 구축하는 방법입니다.

이것이 클라이언트 측 개발자에게 바람직한 이유는 아무도 데이터베이스에서 HTML을 원하지 않는 이유와 거의 같습니다. 클라이언트 측 개발자는 HTML을 처리했을 때와 같이 테이블을 사용하려고 할 때 어떻게해야합니까? 클라이언트에서 모든 것을 처리하는 데 드는 성능 비용은 다른 서버에서 요청하는 것보다 사소합니다. 또한 HTML 빌드는 JS-land에서 꽤 잘 설명되어 있습니다. 데이터를 정렬하고 새로운 HTML 테이블 행을 작성하는 것은 숙련 된 클라이언트 측 개발자에게는 매우 간단한 작업입니다.

그리고 100 % 캔버스 또는 완전히 다른 HTML 구조 인 위젯을 구현하는 것과 같은 이국적인 것을 수행해야하는 다른 장치의 프런트 엔드에 대한 백엔드 아키텍처는 어떤 용도로 사용됩니까? 왜 클라이언트 측 개발자가 비주얼 스튜디오를로드하거나 백엔드 개발자 문을 두드려야만 프레젠테이션을 엄격하게 조정할 수 있습니까?

강력한 형식의 템플릿 유효성 검사 손실에 대한 우려에 대해서는 유능한 클라이언트 측 개발자를 다루는 경우 더 석탄에 적합한 .NET 프레임 워크 또는 Visual Studio 도구를 찾을 수 없다고 말할 때 저를 믿으십시오. s / he보다 올바른 형식의 유효한 HTML에 대해 다이아몬드-대-분쇄 적 분석.

풀 스택 관점에서 볼 때, 비즈니스 또는 앱 로직을 위해 낚시를 할 필요가 없기 때문에 일부 yutz는 템플릿 레이어에 빠지기로 결정했습니다. 최신 컴퓨터를 사용하는 최신 브라우저에서 실제로 사용자의로드 경험을 향상시키는 반면 서버에서 발생하는 사용자 별로드는 말할 것도 없습니다.

백엔드 아키텍처를 모든 프레젠테이션과 완전히 분리하면 추론하기가 더 쉽다고 생각합니다. 더 이상 데이터를 일부 HTML로 매시하지 않습니다. 당신은 다른 쪽에서 수행되는 것보다 일반적인 용도에 더 관심이있는 구현 독립적 인 데이터 구조를 만들기 위해 그것을 모으고 있습니다. 데이터가 이제 프로세스의 두 번째 단계에서 마지막 단계가 아닌 최종 목표이기 때문에 데이터 처리 방식의 일관성이 높아지는 경향이있는 IMO는 관련성이없는 우려로 인해 전선이 교차 될 가능성이 적습니다.

나는 내 주관적인 2 페니 가치를 제공 할 것입니다. 이것에 대한 옳고 그름의 대답은 없으며 다음과 같은 요점 외에도 많은 실제 고려 사항이 있습니다.

• 집에서 관련 경험이 있습니까? 클라이언트 측 구동 앱을 구축하는 것은 완전히 다른 기술 세트를 가진 주로 서버 구동 응용 프로그램과 매우 다릅니다.
• 시간이 얼마나 걸리고 어떤 브라우저를 지원해야합니까? -클라이언트에서할수록 더 많은 브라우저 문제가 발생합니다. IE8은 고통스럽고 JavaScript 성능은 상당히 좋지 않지만 XP / IE 설정을 실행하는 많은 비즈니스가 있습니다.
• 사용자가 어떤 기기를 통해 사이트를보고 있습니까? 최신 버전의 Chrome에서는 자바 스크립트 구문 분석 및 실행이 빠를 수 있지만 이전 휴대 기기에는 있지 않습니다. 특히 비즈니스 로직이 많은 자바 스크립트는 아닙니다.
• 초기 하중은 얼마나 중요합니까? 서버 템플릿이 클라이언트 템플릿보다 빠릅니다.

이 목록은 결코 철저하지 않으며 고객의 의도가 아닌 클라이언트 측 강타처럼 들립니다. 나는 프론트 엔드에 중점을 둔 사이트를 만들었습니다.

나를 위해 그것은 실제로 사용자 경험과 API 재사용성에 달려 있습니다. 이들 각각을 해결합니다.

앱을 만들거나 API를 제공하려는 경우 .Net API 프로젝트를 사용하는 데 많은 의미가 있습니다. 그러면 플랫폼 간 논리, 확인 및 구현이 형성됩니다. 이 시나리오에서는 완전한 클라이언트 측 접근 방식이 선호 될 수 있으며 API를 별도로 유지 관리 할 수 ​​있으며 애플리케이션에 대한 인터페이스 만 제공합니다. 로직을 수정하고 편안하게 리팩터링 할 수 있으며 인터페이스를 동일하게 유지해야합니다. 동일한 백그라운드 코드를 사용하여 다른 미디어에 대해 다른 응용 프로그램을 쉽게 작성할 수 있습니다.

순수한 프론트 엔드 솔루션에 대한 가장 강력한 주장은 사용자 경험에 대한 것입니다.

순수한 JavaScript 브라우저 응용 프로그램이 모든 단점을 고려할 때 기존 웹 사이트의 사용 성과 사용자 경험이 크게 향상 되었습니까?

기본 응용 프로그램처럼 작동하는 사이트를 만들 때 나는 그 대답이 분명하다고 주장한다. 그러나 대부분의 사이트는 이처럼 잘 정리 된 것이 아니기 때문에 개별 사용자 워크 플로가 매우 역동적 인 인터페이스를 통해 이점을 얻는 지 평가해야합니다.

나는 이것에 대해 상당히 실용적인 견해를 가지고 있습니다. JavaScript는 분명히 서버 기술과 함께 매우 행복하게 작동하며 하나를 선택할 필요가 없습니다. 모든 사이트는 단일 페이지 웹 응용 프로그램은 아니지만 개별 페이지에서 녹아웃, 백본 등을 사용하는 것을 막을 수는 없습니다. 필요하다고 생각되는 부분을 개선하십시오.

나는 프론트 엔드 무거운 응용 프로그램과 사랑 관계가 있습니다.

한편으로는 JavaScript 작성을 좋아하고 브라우저를 실행 환경으로 좋아합니다.

반면에, 둘 다 엔진에 구멍이있는 포뮬러 1 경주 용 자동차와 같은 느낌입니다. C #과 JavaScript 간의 비즈니스 로직 중복을 막을 수 있습니까? 그렇다면 가치가 있다고 생각되는보기를 생성하는 방법을 사용하십시오. 두 가지 언어로 비즈니스 로직을 복제하는 경우 JavaScript 만 작성하고 싶지만 큰 그림을 보지 못하는 프런트 엔드 개발자가있을 수 있습니다.

기술적 차이점에 관해서는 :

부분 렌더링 및 클라이언트에 전달 :

• 쉽고 빠른 구현
• 프런트 엔드에서 백엔드 비즈니스 로직이 복제되지 않도록 방지
• 브라우저에 훨씬 더 큰 HTTP 페이로드가 발생할 수 있습니다. 대역폭이 높은 데스크탑에서는 나쁘지 않습니다. 휴대 전화가 약한 경우에는 60mph로 급행 열차 시간에 앉아 있고 1,000 대의 다른 휴대 전화가 동시에 한 셀 타워에서 연결을 끊고 다음 셀 타워에 다시 연결하려고합니다.

JSON 제공 및 클라이언트 측 템플릿 렌더링

• HTML보다 HTTP 페이로드가 더 작을 수 있으므로 응용 프로그램을 신뢰할 수 없거나 느린 네트워크 연결에서보다 반응 적으로 보일 수 있습니다.
• 많은 JavaScript 템플릿 언어가 완전히 기능 하므로 HTML을 생성하기 위해 백엔드 가 필요 하지 않습니다.

때로는 새로운 JavaScript 프레임 워크가 목욕물로 아기를 쫓아 내고 있다고 생각합니다.

마지막 응용 프로그램에서 REST api와 JavaScript 프런트 엔드를 결합했습니다.

내가 한 일은 :

• CRUD 작업을위한 REST API를 만들었습니다.
• 사전 정의 된 HTML 템플리트를로드하고 REST API에서 리턴 된 데이터로 채우는 Javascript 애플리케이션을 작성했습니다.

기본적으로 JS 프론트 엔드는 CRUD 조작을 위해 REST API와 통신하고 리턴 된 데이터 또는 작성된 데이터로 HTML을 채우거나 삭제 된 데이터를 제거하거나 변경된 데이터를 업데이트합니다.

따라서 우리는 순수한 HTML을 가지고 클라이언트에서 처리를 수행하며 모든 HTML을로드하지 않아도 대역폭 사용량이 적으며 사용자에게 웹 2.0을 경험할 수 있습니다.

안전 및 코드 복제를 위해 프런트 엔드에서 비즈니스 유효성 검사를 수행하지 않습니다. 누구나 데이터를 서버로 보내기 전에 데이터를 변경할 수 있으므로 서버의 데이터를 다시 확인해야하기 때문입니다. 따라서 이것은 쉽게 해킹됩니다. 모든 유효성 검사는 백엔드에서 수행됩니다. 클라이언트 측의 유효성 검사는 입력 유형에 대해서만 이루어집니다.

장점 :

• JS가 생성하지 않기 때문에 HTML을 변경하는 기능.
• ajax 및 JSON을 사용하여 대역폭 소비를 줄입니다.
• HTML이 클라이언트쪽에 채워 지므로 서버 처리 비용이 줄어 듭니다.
• JS를 사용하여 화면을 변경하여 효과를 사용하고 렌더링 속도를 높여 사용자 환경을 개선했습니다.
• REST를 사용하여 HTTP 프로토콜을 더 잘 사용하십시오.

단점 :

• 유지 될 2 개의 신청;
• 하드웨어 처리 불량으로 인해 클라이언트 처리에 따라 다릅니다.

도움이 되었기를 바랍니다.

문안 인사,

validation웹 API 의 측면 과 관련하여 - "모델 유효성 검사"를 수행하고 400 잘못된 요청 http 응답으로 응답 할 수 있습니다.

/programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285를 참조 하십시오.