Bạn đang thực sự hỏi nhiều hơn một câu hỏi. Tôi hiện đang phân tích câu hỏi "tôi nên sử dụng khung công tác gì" cho công ty của chúng tôi. Điều này đòi hỏi nhiều hơn bạn nghĩ. Dưới đây là những gì tôi có cho đến nay, và khi tôi nhận được thêm chi tiết, tôi sẽ cố gắng cập nhật mục này.
Trong thời gian chờ đợi ...
Câu hỏi về các mẫu kiến trúc khác với các thư viện hoặc khung công tác.
ARCHITECTURAL DESIGN PATTERNS hữu ích vì nhiều lý do. Một lý do sẽ là để đạt được khớp nối lỏng lẻo trong các mô-đun của bạn. Một ví dụ tuyệt vời về cách đạt được khớp nối lỏng lẻo được tìm thấy trong Mediator Pattern.
Câu hỏi trong đó khuôn khổ để sử dụng có nhiều điểm quyết định:
thử nghiệm Tốc độ:
Những Are Những gì tôi xem xét các khuôn khổ:
tôi đã quyết định để hạn chế LỰA CHỌN CỦA KHUNG tôi để:
- Dojo: Toolkit, Desktop, Mobil, Graphics & Vectoring
- YUI: Công cụ nhà phát triển, cơ sở hạ tầng, tiện ích, Widgets, bộ sưu tập , Dự án
- jQuery: Lõi, giao diện người dùng, Mobil, Plugins, đồ thị, trực quan hóa
... Nhưng một phân tích về thư viện JavaScript cũng là cần thiết:
MVC là mô hình front-end thường được sử dụng nhất. Tuy nhiên, ghi chú của tôi ở đây chưa hoàn tất. Ngay cả khi tôi gặp khó khăn khi tìm số liệu thống kê sử dụng trên các mục được liệt kê ở trên.
Backbone.js (MVC)
Được thiết kế nhiều hơn để tiêu thụ dữ liệu REST. Backbone có hệ thống sự kiện riêng, và do đó, cạnh tranh với chức năng jQuery.
Spine.js (MVC)
JavaScriptMVC (MVC)
MVC tích hợp các công cụ phát triển; được sử dụng với jQuery; Được mô đun hóa cao. Chưa chắc chắn nếu nó chỉ đơn giản có thể được coi là một thư viện hay không ... nhưng daddy likey!
AngularJS (MVC)
Tách mối quan tâm, khớp nối lỏng lẻo và đảo ngược kiểm soát. Hai chiều databinding
SproutCore (MVC)
YUILibrary (MVC)
Đây thực sự là một phần của khuôn khổ YUI tổng thể ... nhưng đã được liệt kê trong bản gốc source article.
Broke.js (MVC)
Tài liệu hiện kém.
Fidel.js (MVC)
Sammy.js (MVC)
Được thiết kế hơn đối với tiêu thụ dữ liệu REST.
KnockoutJS (MVVM)
CÂU HỎI:
- Tại sao có quá ít hiện thực MVVM hoàn toàn?
- Hai chiều có ràng buộc giống như MVVM không?
- Nếu vậy, tại sao một số thư viện trong số này (liên kết hai chiều) tự coi mình là MVC?
MODULAR JAVASCRIPT:AMD, CommonJSvà Promises-Based Triển khai:
tôi vẫn đang phác thảo khu vực này. Tuy nhiên, dưới đây là một số lĩnh vực tôi đang sử dụng cho cảm hứng.
CÂU HỎI:
- Có khác nhau 'hương vị' của AMD (bài viết khác nhau dường như nói có)?
- 'Dựa trên lời hứa' có nghĩa là gì?
tạo widget & PLUGINS:
Khi bạn quyết định mà hương vị của AMD module bạn nên sử dụng bạn thực sự có thể bắt đầu ghi chép lại một cái gì đó.
CÂU HỎI:
- sự khác biệt giữa một plugin và một widget là gì?
LƯU Ý CHUNG:
tôi sẽ đề nghị xem xét làm thế nào mỗi khung của bạn thực hiện các module khác nhau. Nhìn vào mã nó cần để hoàn thành một cái gì đó. Nó có cảm thấy đúng không? Liệu nó có cảm thấy vụng về?
MY BAN ĐẦU FEELING:
Nhìn vào xu hướng, sử dụng, tốc độ và sự bao la của tùy chọn hỗ trợ cộng đồng ... jQuery là con đường phía trước.
CÁC MỤC TIÊU:
Mục đích cuối cùng là để chọn một khuôn khổ, bất kỳ/tất cả các thư viện và xác định một cách tiếp cận chung để tải và tạo lỏng lẻo-coupled Modules JavaScript.
Định lượng chi phí theo rủi ro:
Chi phí định lượng hoàn toàn khó, nhưng bạn có thể giải thích rủi ro. Trong desicion cuối cùng của bạn, bạn cũng nên đưa vào tài khoản các xu hướng được liệt kê ở trên. Nhưng, nói chung, tôi sẽ lỏng lẻo break-up chi phí thành 3 khu vực để xác định RỦI RO:
- Quen thuộc: nhóm của bạn là gì quen thuộc nhất với bây giờ?
- Ramping Up: Sẽ tốn bao nhiêu công sức để "tăng tốc" trên mỗi khung và thư viện?
- Cấp phép: Có bất kỳ snags nào ở đây không?
Rủi ro: Khi được đánh giá, bạn có thể giải thích hợp lý TẠI SAO bạn có thể xếp hạng một tùy chọn thấp, trung bình hoặc cao.
@ErezCohen
Chúng tôi là một cửa hàng ASP.NET, vì vậy chúng tôi sử dụng Web API cho backend RESTful của chúng tôi. Và kể từ khi phát triển JavaScript kiểu thành phần là tương lai, chúng tôi đã chọn sử dụng jQuery & RequireJS làm tiêu chuẩn cơ sở trên tất cả các trang của chúng tôi. Ngoài ra, chúng tôi sử dụng rất nhiều Hoãn trong bộ điều khiển của mình.
Đối với MVC phía máy khách, quá nhiều "khung công tác" được đề cập là mốt nhất thời hơn bất kỳ thứ gì khác (và nhiều loại đã bị sử dụng). Ngoài ra, nó có ý nghĩa hơn để xử lý các khả năng MVC/MVVM như là một phần bổ trợ một lần khi các yêu cầu được đưa ra chứ không phải là một tiêu chuẩn. Và, thành thật mà nói, vì chúng tôi thấy việc thực hiện cuộc gọi Ajax dễ dàng, các khung công tác rộng lớn để thực hiện ràng buộc dữ liệu đơn giản dường như ngớ ngẩn (lợi ích thực sự duy nhất là ràng buộc hai chiều cho một số trường hợp phức tạp). Bên cạnh đó, hãy suy nghĩ về những gì một nỗi đau nó sẽ được để decouple một số các khuôn khổ này một khi họ không còn phổ biến.
Tất nhiên, chúng tôi có tài năng để tự làm như vậy… bạn có thể không. Nếu phi hành đoàn của bạn không giỏi với JavaScript, hãy thử Angular vì nó được phát triển cho “nhà thiết kế” chứ không phải lập trình viên. Ngoài ra, nếu nhóm của bạn có khả năng tự sản xuất và muốn có một khung công tác cho bộ điều khiển thì jQuery Widget Factory rất hữu ích. Tuy nhiên, việc sử dụng đơn giản Mô-đun mô-đun cho bộ điều khiển của bạn cũng tốt (đó là những gì chúng tôi làm). Và ... nó hoạt động rất tốt ... và rất sạch sẽ.
Tôi rất tò mò muốn biết bạn đã chọn gì. + Bạn đã xem Kendo chưa? –
Có, chúng tôi sử dụng các điều khiển Kendo ngay hôm nay. Vấn đề với Kendo MVC là khớp nối nặng với bộ điều khiển của nó ... bạn phụ thuộc vào Kendo. Bạn trở thành một cửa hàng Kendo. Bên cạnh đó, ngày nay, không một bộ điều khiển nào sẽ cung cấp cho bạn tất cả các khả năng bạn cần. Kendo làm tốt ở một số thứ và kinh khủng ở những người khác. Trong khi đó, các thư viện điều khiển khác như Synchfusion hay RGraph đang thiếu nơi Kendo rất tuyệt. Cuối cùng, bạn phải sử dụng nhiều bộ công cụ để cung cấp các yêu cầu kinh nghiệm ra lệnh. Và, vì Kendo MVC được kết hợp chặt chẽ với các điều khiển Kendo… chúng tôi không sử dụng phần Kendo đó. –