Knockout JS 대신 Knockout MVC를 사용하는 이유가 있습니까?

Knockout JS 대신 Knockout MVC를 사용하는 이유가 있습니까?

---

다른 사용자 는 일부 AJAX 게시 문제를 처리하기 위해 Knockout MVC 를 제안 했습니다. 나는 그것에 대해 조금 읽었고 Knockout JS 주위의 래퍼라는 것을 알았습니다 . 그래서 두 사람의 진짜 차이점은 무엇일까요? Knockout MVC 가 존재하기 때문에 Knockout JS로 귀찮게해야합니까 ? 언제 다른 하나를 사용합니까?

---

Knockout MVC는 WebForms의 자식입니다 . 컨트롤러 작업을 통해 모든 뷰 모델 메서드를 라우팅합니다. 즉, 발생하는 모든 것이 서버로 바운스되고 다시 돌아와야합니다. 나는 왜 누군가가 CLIENT SIDE MVVM이 될 녹아웃과 같은 프레임 워크를 사용하여 모든 기능에 대해 서버를 호출하도록하는 이유를 이해할 수 없습니다.

또한 서버에서 이러한 메서드를 수행한다는 것은 모든 함수 호출에 대해 전체 뷰 모델 을 서버로 전달하고 클라이언트로 다시 전달해야 함을 의미합니다 . 이것은 엄청나게 낭비입니다.

Knockout MVC를 사용한다는 것은 자바 스크립트를 작성할 필요가 없다는 이점을 위해 클라이언트 측 코드의 모든 성능 이점을 희생한다는 것을 의미합니다. 동일한 트레이드 오프 WebForms가 만들어졌습니다. 좋은 것이 아닙니다. 반 패턴입니다.

Knockout MVC가 내일 죽으면 웹이 더 나은 곳이 될 것입니다.

---

나는 꽤 부정적인 반응을 보이는이 질문을 만났습니다. 2 센트 가치를 빠르게 추가하겠습니다.

방금 KnockoutJS를 사용하기 시작했습니다. ASP.NET MVC 앱을 빌드하고 있기 때문에 Knockout MVC와 같은 것을 사용하는 것이 논리적으로 보였습니다. 대부분의 경우 좋은 생각처럼 보입니다. 내가 <!-- ko -->알고 좋아하는 .Net 기능을 사용하여 동일한 작업을 수행 할 수 있다면 내 페이지를 통해 자바 스크립트와 주석을 작성하는 데 시간을 소비하고 싶지 않습니다 .

그렇습니다. 현재 KMVC에는 한계가 있습니다. 전체 모델을 서버로 다시 보내는 것은 큰 일입니다. 그래서 제가 한 일은 knockout-mvc의 포크를 시작하는 것입니다. 변화는 필연적으로 현재 급하게 진행되었습니다. 하지만 이제 다음과 같은 능력이 있습니다.

• 하위 컨텍스트 생성 (뷰 모델의 완전히 다른 모델 또는 구성 요소 사용)
• 서버를 호출 할 때 모델의 선택된 부분을 다시 전달
• 전송 된 것과 다른 모델이 호출에서 돌아올 것으로 예상
• ajax 호출 주변의 이벤트 발생
• 더 많은 html5 입력 유형 지원
• 헤더를 통해 위조 방지 토큰을 서버에 전달 (Ajax 호출의 경우)
• 아마 더 잊었을 것입니다

나는 곧 돌아와 내가 한 일을 정말로 정리하기를 바랍니다. 저자는 이러한 변경 사항을 자신의 코드에 포함 시키길 바랍니다. 그렇지 않다면 내 포크를 계속 사용할 것입니다. 어느 쪽이든 터널 끝에 빛이 있습니다. KMVC는 그 자체로 작업이 필요할 수 있지만 그 개념은 확실히 가치가 있다고 생각합니다.

나는 확실히 생각한다

Knockout MVC가 내일 죽으면 웹이 더 나은 곳이 될 것입니다.

조금 가혹했습니다.

편집하다:

저는 댓글을보고 원래 질문이 무엇인지 다시 살펴 보았습니다. 그렇게하면 내 대답에 조금 더 추가해야한다고 생각합니다.

첫째, 원래 질문은 Knockout JS 대신 Knockout MVC를 사용하는 이유가 있습니까? 답변 / 명확하게하기 위해 (아마 난 그냥 까다로울 수도 있습니다) : Knockout MVC는 KnockoutJS를 ASP.NET MVC 앱과 쉽게 통합 할 수 있도록 설계된 프레임 워크입니다. 주로 익숙하고 강력한 형식의 구조를 사용하여 KnockoutJS 태그를 생성합니다. KnockoutJS를 대체하지 않습니다. 반드시 KnockoutJS를 사용하십시오. 문제는 마네 MVC를 사용할지 여부를 정말 뿐만 아니라 .

그렇긴하지만, 사용 가능한 모든 도구의 다양한 측면을 언제 사용할지 선택할 수있는 선택은 개발자의 몫입니다. 서버에 대한 전체 요청을 수행하여 기능의 특정 측면을 처리하려면 그렇게하십시오. 데이터를 검색 / 업데이트하기 위해 ajax 요청을 수행하려면 그렇게하십시오. 순전히 클라이언트 측 기능을 수행하려면 그렇게하십시오.

Knockout MVC를 사용 한다고해서 KnockoutJS를 최대한 활용할 수있는 것은 아닙니다 . Knockout MVC 를 사용해도 원하는만큼 많은 클라이언트 측 기능을 처리하기 위해 추가 자바 스크립트를 작성하는 것을 막을 수 없습니다 . Knockout MVC가 서버에 대한 ajax 콜백을 생성하는 바로 가기를 제공 한다고해서 반드시 사용해야하는 것은 아닙니다 . 응용 프로그램이 데이터를 유지한다면 어느 시점에서 집에 전화해야 할 것입니다.

정적 HTML 및 스크립트 파일을 제공하기 위해 Apache를 사용하는 것과 비교하여 ASP.NET MVC를 사용하여 애플리케이션 백엔드를 빌드하는 이유가 있습니다. Knockout MVC를 사용하면 KnockoutJS 통합을 지원하기 위해 동일한 이점을 계속 활용할 수 있습니다.

---

Tyrsius의 대답이 너무 부정적이라고 생각합니다. Knockout MVC는 아직 초기 개발 단계에 있지만 예를 들어 Webforms보다 몇 가지 장점이 있고 서버가 덜 무겁다는 것을 알 수 있습니다. 가시성 종속성은 함수를 사용할 때만 서버에 대한 호출이 수행되는 경우에만 클라이언트에서 핸들을 얻습니다. 복잡한 데이터 구조로 작업 할 때 때때로 서버를 거쳐야 할 때가 있으므로 Knockout MVC는 많은 Ajax 처리를 직접 작성하는 데 좋은 방법이 될 수 있습니다.

항상 전체 모델을 앞뒤로 보내므로 직접 빌드하는 것과는 반대로 약간의 오버 헤드가 발생하는 것은 사실입니다. 그러나 나는 그것을 완전히 쓰지 않을 것입니다. 특히 향후 복잡한 유효성 검사를 위해 적절한 클라이언트 측 처리를 얻을 때.

---

녹아웃 mvc에 대해 조금 검색 한 후이 게시물을 보았습니다. 네트워크 대역폭 낭비에 동의하지만 그 코드 줄에 상당히 매료되었습니다.

@{
  var ko = Html.CreateKnockoutContext();
 }

녹아웃 뷰 모델을 생성하는 깔끔하고 깔끔한 방법입니다. 누구든지 해당 기능을 위해 모든 로직을 서버 측으로 이동하지 않고 녹아웃 MVC를 사용 했습니까?

---

Knockout.js의 장점은 HTML을 생성하기 위해 서버가 청크해야했던 전체 뷰를 푸시 할 필요없이 서버에서 JSON을 앞뒤로 전달하여 애플리케이션을 제공 할 수 있다는 것입니다.

다시 서버에 다시 넣는 것은 매우 직관적이지 않습니다! 관심이 있다면 처음부터 바인딩을 수행하기 위해 면도기 구문을 사용하는 것이 좋습니다.

내 제안은 knockout.js를 사용하여 바인딩을 수행하여 이것이 목표 인 경우 바인딩이 서버가 아닌 클라이언트에서 발생하도록하는 것입니다. 뷰가 서버에서 데이터 바인딩되도록하려면 razor를 사용하세요.

---

또한 knockout.js는 클라이언트 측 데이터 표시 / 삭제 / 삽입 / 업데이트 및 클라이언트 측 데이터 계산에 매우 능숙합니다. 실제 비즈니스 로직이 그렇게 간단하다면 knockout.js를 직접 적용해야합니다.

진실은 비즈니스 로직이 항상 그렇게 단순하지는 않다는 것입니다. 예를 들어, 클라이언트가 뷰에 새 레코드를 삽입 할 때 시스템은 사용자의 인증을 확인하고 일부 비즈니스 로직 또는 공식을 기반으로 새로 생성 된 객체에 대한 기본값을 설정해야합니다.이 모든 것은 어쨌든 서버 측으로 가서 확인해야합니다. 데이터베이스 데이터에 기반한 논리.

개발자는 모든 필수 비즈니스 로직을 knockout.js 뷰 모델 내에서 자바 스크립트 메소드로 변환 할 수 있습니다. 그러나 이런 식으로 설계는 중앙 집중식 비즈니스 로직 처리 규칙을 위반합니다.

유지 보수는 그러한 디자인에 악몽이 될 것입니다.

요약하자면, 어떤 프레임 워크 선택이 비즈니스 요구 사항에 실제로 의존하는지. 때로는 성능이 첫 번째 고려 사항이 아닙니다.

---

또한 Knockout MVC 라이브러리를 사용하여 많은 좋은 사용 사례를 볼 수 있습니다. 예를 들어 @ChinaHelloWorld가 지적한 이유 때문에 KnockoutJS를 MVC 웹 앱에 거의 통합 할 수 없었습니다. 다음은 매우 도움이되는 몇 가지 사례입니다.

1. 강력한 형식의 바인딩

I liked the nice strongly-typed HTML helpers methods, which became completely useless and messy when it came to setting up KnockoutJS. The best thing I could do is to manually attach my binding attributes with the extra parameter of the helper methods, but I had to use magic strings there again. I like the helpers provided by Knockout MVC for creating inputs and other elements with strongly-typed, C# expression based bindings. However, here I would like to mention that I miss the name attribute of the generated fields, so I needed to tweak it a little.

2. Strongly-typed binding syntax (kind of)

When using pure string bindings, there is always a good chance of misspelling, or not exactly knowing the correct format of the binding which you'd like to apply. With the fluent API of Knockout MVC and the VS IntelliSense it's really easy to apply the correct bindings.

3. (Almost) Automatic conversion from computed C# properties to computed bindings

Just with application of the small [Computed] attribute, Knockout MVC can generate the corresponding binding expression in correct KnockoutJS syntax. This one is very useful as well I think.

4. No viewmodel code duplication

In the classic way, I needed to have the viewmodel class in C# code, and then (nearly) the same viewmodel code in JS (with observables). Well, THAT was frustrating for me, and I got extremely happy when I saw the technique used in Knockout MVC. However, I needed to tweak it a bit for being able to use it with really complex viewmodels (nested viewmodels, collections, etc.), and to be able to extend the mapped Knockout viewmodels with for example any needed custom JS method or computed observable.

So here are at least four very good points. And about viewmodel round-trips: no-one told that anyone of us need to use the server-side processing mechanism of Knockout MVC. I wouldn't use that either, only if there is some complex business logic which really needs to be processed on the server. But in most cases, Knockout MVC is just for simplifying the binding and setup process of MVC Views and KnockoutJS. So I don't quite understand the bad opinions above. I think who wrote these opinions did not take the effort to learn at least the basic concepts of Knockout MVC. Yout definetely should NOT use Knockout MVC instead of KnockoutJS, but besides KnockoutJS. Understanding Javascript and at least the basics of KnockoutJS is still mandatory in any case.

I wish the author continued the development of Knockout MVC, because besides these good points, there are some features and refinement which would really make it even more powerful.

---

In .Net MVC pattern, view model already marking into each view/partial view clearly with tag "@model yourmodel", which can guide developer to understand what will do in this view.

When using knockout.js MVVM pattern, you possibly would not see any .Net view model, except tags like "data-bind" in the views. This would make the view and controller uncoupled and difficult to track logic specially for a new developer in a team.

I believe knockoutMVC can solve such difficulties and saving a lot of javascript codes which will make the system difficult to maintain and understand.

Since knockoutMVC makes the design still stick on applying server-side view model which is easy to track and maintain since it is the C# code.

For a business project, manager should always focus on easy to develop, easy to maintain, easy to upgrade and easy to understand and quickly delivered to make money.

Sacrifice a little bit of performance but make it simple, consistency at client-side and server-side should be a key point. Javascript is a big maintenance issue.

Does it really a matter sending back the whole view model back to server-side? If it does, we can split a big model to several small models.

---

You still have the performance if you are not using functions generated by komvc. As Nigel said, the initial page generation would still have to be server generated. You can always add user scripts and create functions on the client side that won't need to go back to the server. It's a tool that gives the developer a bit of productivity. The comparison with web forms on performance is sure exaggerated. Folks, that's one tool that sure helps you meet your deadline.

---

I will add my 2 cents in favour of knockoutjs, though it is little complicated to write compared to knockout MVC, the benefit you get is huge when it comes to re-usability. The client code can work harmoniously with other technologies as well.

Keeping aside the security perspective I personally feel knockout js is a way of complicating asp.net MVC and it should be used as is (knockout js) with pure RESTful applications such as asp.net webapi.

---

Knockout MVC is a powerful extension for ASP .NET MVC that allows you to implement the website client functionality directly on your .NET project using developer friendly fluentAPIs without Javascript and removing a lot of duplicated and repetitive code.
knockout MVC is the same as coding ASP .NET MVC razor and you get the client functionality without any extra hassle.
You won't have to code a view model and lines of binding code.
I have been using koMVC on most of my websites and the develop time reduction, easy maintenance and mininal learning curve are a huge payoff.
I suggest you check their website and have a go with some live examples. http://knockoutmvc.com
It wont take long for you to fall in love with it.

---

MVC is an architecture pattern which separate into three component, Model, View and Controller.

KnockoutJS work best with the MVC architecture because the framework’s data binding require the use of controller. There are frameworks such as AngularJS which focuses more on the front end and therefore they work better with the MVVM architecture pattern (model, view, view model). Their data binding features also doesn’t require the use of controller which reduce the scope of binding.

ReferenceURL : https://stackoverflow.com/questions/11618042/is-there-a-reason-i-would-use-knockout-mvc-instead-of-knockout-js