Chuyển từ ASP truyền thống. NET MVC đến WebApi + Knockout

Question

Tôi vừa đọc một bài viết thú vị về cách Microsoft dường như đang chuyển sang một giao diện REST + phát triển MVVM dựa trên javascript phía máy khách cho các ứng dụng web. Mặc dù về mặt kỹ thuật tôi đã hiểu được sự khác biệt cơ bản giữa hai mô hình, tôi hoàn toàn nhầm lẫn về những tác động của nó về cách viết ứng dụng web và quan trọng nhất là chuyển đổi một cách duyên dáng sang mô hình mới này.

Vì vậy, đối với một người nào đó di chuyển từ truyền thống ASP.NET MVC để WebAPI + KO, các câu hỏi sau phát sinh:

• Có cách nào để có (tức là tối thiểu code) xác nhận không phô trương hoặc gần như không phô trương sử dụng MVC + KO?
• Làm cách nào để một đơn vị kiểm tra mã giao diện người dùng của mình?
• Tính tương thích của trình duyệt có bị KO không?
• Có điều gì khác mà người khác phải xem xét khi chuyển từ mô hình này sang mô hình khác không?

Answer 1

Bạn thấy Microsoft bắt đầu đẩy điều "ứng dụng web một trang" này một phần vì nó có thể mang lại trải nghiệm người dùng tốt hơn nhưng chủ yếu là vì nó giúp di chuyển ứng dụng web của bạn trở thành ứng dụng gốc Windows 8 dễ dàng hơn nhiều .

Re: không phô trương javascript để xác nhận ... Tôi sẽ nói rằng nếu bạn đang sử dụng Knockout, bạn là giao diện người dùng và tập lệnh của bạn sẽ được kết nối chặt chẽ ngay cả đối với những thứ cơ bản mà không phô trương thực sự không phải là mục tiêu hợp lệ. Bạn có thể làm xác nhận trong Knockout (xem https://github.com/ericmbarnard/Knockout-Validation#readme ví dụ) nhưng nó không phải là không phô trương theo định nghĩa tương tự như ASP.NET MVC

Re: kiểm tra đơn vị ... hãy nhìn vào https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit

Re: Trình duyệt compat. .. Tôi không biết bất kỳ vấn đề tương thích nào với bất kỳ trình duyệt hiện đại nào trừ khi bạn có những người dùng điên đã tắt JavaScript

Answer 2

Tôi đã tìm thấy this là một cuộc thảo luận thực sự tốt đẹp về những ưu và nhược điểm của việc cố gắng "không phô trương" một trang web Knockout. Theo truyền thống, tôi rất ủng hộ việc giữ Javascript một cách kín đáo nhất có thể, và với các biểu thức Knockout của tôi, tôi cố gắng giữ chúng càng nhỏ gọn và gọn gàng càng tốt bằng cách dịch chuyển bất kỳ vật nặng nào vào các chức năng trên mô hình khung nhìn của tôi và tạo tùy chỉnh các ràng buộc đóng gói logic DOM - nhưng tôi chắc chắn về ý kiến ​​rằng chính phương pháp khai báo đó (chẳng hạn như mặc định sử dụng thuộc tính ràng buộc dữ liệu), khi được sử dụng một cách hợp lý, là con đường để đi.

Có lẽ vì tôi giới thiệu Knockout là một ứng dụng web "cổng" của một ứng dụng WPF mà tôi đã làm, và các ràng buộc Knockout của trang web của tôi đang trở nên gần gũi với XAML tương đương như tôi tìm hiểu thêm về cách tận dụng Knockout duyên dáng. Tôi chỉ thích có thể đánh dấu nhãn cầu và xem lướt qua logic kinh doanh thực về cách xem được đánh giá, thay vì chi tiết cụ thể về cách jQuery hoặc bất cứ thứ gì thể chất xây dựng nó để đáp ứng với một số sự kiện nhấp có dây trong một linh hồn lớn phá hủy Javascript tập tin.

Khi tôi truy cập lại một số trang MVC truyền thống của tôi, sử dụng nhiều thủ thuật jQuery để kết nối mọi thứ, tôi nghĩ, đánh dấu là gọn gàng, nhưng quay trở lại sau 6 tháng thậm chí tôi khó hiểu ý định của tôi là gì với tất cả các bộ chọn jQuery, callbacks và DOM traversals. Tôi nghĩ rằng tôi sẽ chỉ áp dụng các ràng buộc Knockout tự động nếu tôi phải, tức lànếu có một tình huống mà logic ràng buộc của tôi là bản năng động - nhưng điều đó có lẽ có thể được hoàn thành khác với các mẫu động.

Đó là 2 xu của tôi trên khía cạnh không phô trương của câu hỏi của bạn và nếu trải nghiệm của bạn chuyển sang MVVM Javascript thì mọi thứ như tôi đã trải qua vài tháng qua, bạn sẽ không nhìn lại.