backbone.js를 ASPNET MVC와 통합하는 것이 합리적입니까?

backbone.js를 ASPNET MVC와 통합하는 것이 합리적입니까?

---

저는 이러한 빌딩 블록에 대한 전문가는 아니지만 언뜻보기에는 다음과 같은 것 같습니다.

• ASPNET MVC는 서버 측에서 앱에 대한보기를 생성하고 모델을 관리하려고합니다. 브라우저를 서버에서 제공하는보기의 소비자 인 다소 멍청한 프레젠테이션 엔진으로 간주합니다.

• backbone.js는 브라우저에서 뷰를 생성하고 모델을 관리하려고합니다. 서버 측을 상당히 멍청한 REST 기반 지속성 엔진으로 간주합니다.

이것은 단순한 견해처럼 보입니다. 나는 그것이 전체 이야기가 아니라고 확신합니다.

이 두 가지를 통합 할 수있는 진정한 기회는 무엇입니까? 그것을하는 것이 합리적입니까? 아니면 이해하기에는 너무 겹치는 부분이 있습니까?

누군가 나를 추천 할 수 있다면 이것에 대한 분석이나 토론을보고 싶습니다.

---

backbone.js에 대해 말할 수는 없지만 ASP.NET MVC와 결합하여 녹아웃을 사용하여 큰 효과를 냈다고 말할 수 있습니다. 지금까지 본 모든 ASP.NET 응용 프로그램은 클라이언트 측 및 서버 측 뷰 생성을 혼합하여 사용합니다. 서버 측 뷰를 생성하는 것이 더 편리한 때가 항상있을 것입니다. 예를 들어 사용자가 인증되었는지 여부 또는 특정 권한이 있는지 여부에 따라 조건부 UI 요소를 사용합니다. 웹에 정통한 사용자가 클라이언트 측 템플릿을 탐색하고 그들이 얻지 못하는 모든 기능을 해결하는 것을 원하지 않을 수 있습니다. 물론 다른 클라이언트 템플릿을 비동기식으로로드하여이 문제를 해결하거나 서버 측 코드를 작성하여 클라이언트 측 템플릿을 생성 할 수 있습니다. 또한 SEO가 당신에게 의미가 있다면,

제 생각에 가장 좋은 점은 둘 다 잘하는 것입니다. 내 경험상 ASP.NET MVC가 두 가지 모두에서 탁월하다는 것을 알았습니다.

ASP.NET MVC가 멋진 이유

• 레이아웃 (MasterPages)
• Razor (인텔리 센스의 장점이있는 형식이 안전한 뷰)
• ActionFilters (로깅, 인증 등과 같은 규칙을 적용하기위한 멋진 장소)
• 무료 JSON 직렬화- return Json(model)
• 모델 바인딩 및 검증
• IoC와 MVC는 가장 친한 친구입니다 (승리)
• 인증 + 권한
• 내가 생각할 수없는 다른 많은 것들.

뷰 생성을 위해 클라이언트 측 프레임 워크를 사용하면 실제로 놓친 것은 Razor뿐입니다. 레이아웃을 어느 정도 활용할 수도 있습니다.

ASP.NET MVC를 사용하여 개발하는 방법은 응용 프로그램이 서버 측에서 작동하도록 만드는 것입니다. 이것은 당신이 원하는 URL 구조, 컨트롤러가 필요한 것, 경로가 무엇인지 생각하도록 강요합니다. 또한 뷰를 처음 반복하는 동안 유형 안전성 및 자동 완성의 이점을 얻을 수 있습니다. 이 연습을 마치면 Google이 충분히 얻을 수없는 사람에게 알려진 모든 장치에서 작동하는 간단한 표준 준수 솔루션이 있습니다.

그런 다음 클라이언트 측 기능의 일부를 구현하는 점진적 접근 방식을 취했습니다. 클라이언트 측에서는 AJAX 요청으로 전환하려는 요청을 하이재킹하는 자바 스크립트를 작성하고 번역 된 버전의 Razor 뷰를 사용하여 응답을 처리합니다. 서버 측에서는 액션 필터를 사용하여 규칙 기반 접근 방식을 취합니다. 이 작업 필터는 대략 다음을 수행합니다.

• ActionResult가 ViewResult입니까?
  • 수락 유형은 무엇입니까?
    • HTML-동일한 모델에서 "_"접두사가 붙은 동일한 이름의 PartialViewResult를 반환합니다.
    • JSON-동일한 모델이 지정된 JsonResult 반환
• ActionResult가 RedirectToRoute 결과입니까?
  • EmptyResult 반환 (또는 선택적으로 JsonResult에서 URL을 반환 할 수 있음)

이 접근 방식을 사용하면 컨트롤러에서 한 줄의 코드를 변경하지 않고도 AJAX 기능을 추가 할 수 있습니다. 대체 접근 방식은 Thunderdome Principal 을 따르고 요청 컨텍스트를 기반으로 적절한 결과 유형으로 모델을 래핑하는 ActionInvoker를 갖는 것입니다. 나는 서버 측 탐색 (리디렉션) 이이 접근 방식에 어떻게 적합한 지 알아 내지 못했습니다.

서버 측 구현에서 시작하는 낭비는 뷰 생성 코드 (Razor + js 기반 템플릿)가 두 배로 늘어난다는 것입니다. 클라이언트에서 구현하려는 애플리케이션의 양에 따라 이것은 문제가 될 수도 있고 아닐 수도 있습니다. Spark는 실제로 클라이언트 템플릿 을 생성 할 수 있다는 점에서 예외입니다 ! Spark의 단점은 중요하지 않은 손실이 아닌 intellisense (플러그인이 있지만 쓰레기)를 잃는다는 것입니다. 게다가 저는 Razor를 선호합니다 (구워졌고 구성 할 필요가 없으며 언제든지 사라지지 않음). 곧).

---

나는 asp.net mvc KO와 bakcbone을 다른 프로젝트에 사용했으며 결국 프로젝트의 성격에 모두 귀속됩니다. 워크 플로우가 복잡해지기 시작하거나 단순한 데이터 데이터 중심 애플리케이션과 달리 UX를 제공하려는 경우 서버 스택은 즉시 사용되지 않습니다. 당신의 프로젝트가 훌륭한 UX backbonejs를 포함한다면 당신은 거기에 도달 할 수 있습니다. Btw backbonejs를 위해 KO를 모의 할 수있는 플러그인이 있습니다. .. 나는 bacjbone.modelbinder를 다시 언급하고 있습니다. Cuz MS는 전혀 신경 쓰지 않을 것입니다.

참고 URL : https://stackoverflow.com/questions/7694161/does-it-make-sense-to-integrate-backbone-js-with-aspnet-mvc