อะไรคือจุดแข็งและจุดอ่อนในโลกแห่งความเป็นจริงของกรอบงานหลาย ๆ แบบบนพื้นฐานของ backbone.js? [ปิด]

หวังว่าบางคนสามารถแบ่งปันประสบการณ์กับ backbone.js ล่าสุดที่ออกใหม่บางรุ่นได้ ฉันมีประสบการณ์ที่ดีกับแบ็คโบน / ขีดล่าง / จำเป็นในหลายโครงการและฉันอยากจะใช้ขั้นตอนต่อไปเพื่อแก้ปัญหาขั้นสูงสำหรับโครงสร้างแอปพลิเคชันที่ซับซ้อน

ฉันรู้ว่ามีกรอบงานดังต่อไปนี้:

• หุ่นเชิด
• Geppetto (อิงจากหุ่นกระบอก)
• แชปลิน , แชปลิน - แชปลิน-สำเร็จรูป
• สัตว์มีกระดูกสันหลัง
• LayoutManager
• ทรวงอก
• กลิ่นอาย
• Luca
• Singool
• backstack
• Backbone UI

• ซากเรือเก่า ๆ

• BTW - จุดเริ่มต้นที่ยอดเยี่ยมสำหรับโครงการขนาดใหญ่

และบางทีฉันอาจพลาดบางอย่าง

มีการแนะนำสั้น ๆ เกี่ยวกับความแตกต่างที่นี่:

• ลิงก์พูดคุยของ speakerdeck

แต่มันธรรมดามาก ฉันสงสัยว่าใครบางคนสามารถแบ่งปันประสบการณ์กับแอปพลิเคชันในชีวิตจริงโดยใช้กรอบการทำงานเหล่านี้

อะไรคือประโยชน์ของการเลือกอันใดอันหนึ่ง? หุ่นกระบอกจะเป็นทางออกที่ดีกว่าแชปลินหรือทำไม vetebrae ถึงดีกว่าสำหรับแอปพลิเคชันบางตัว

แน่นอนว่าคำตอบที่ชัดเจนจะ " ใช้สิ่งที่ดีที่สุดสำหรับความต้องการของคุณ " แต่ฉันขาดประสบการณ์กับกรอบเหล่านี้เพื่อทราบจุดแข็ง / วัตถุประสงค์ / ข้อดีของพวกเขาหรือสถานการณ์ที่ต้องการ

ขอบคุณ!

แก้ไข 1: พบโพสต์นี้: Backbone.Marionette vs Backbone-Boilerplate

แก้ไข 2: ตอบโดย Mathias schafer (แชปลิน) ทางไปรษณีย์:

กล่าวโดยสรุปโครงสร้างปัจจุบันใกล้เคียงกับรุ่น 1.0 เนื่องจากใช้ในการผลิตแล้ว เราไม่ได้วางแผนที่จะเพิ่มคุณสมบัติใหม่ขนาดใหญ่หรือทำลายการเปลี่ยนแปลง API จนถึง 1.0

หุ่นกระบอกนั้นเป็นห้องสมุดที่ครอบคลุมและมีเสถียรภาพมากที่สุด มันกล่าวถึงแง่มุมต่าง ๆ ของการพัฒนาแอป JS ด้วย Backbone ตัวอย่างเช่นมันมีเลเยอร์มุมมองที่แข็งแกร่งซึ่ง Backbone นั้นปล่อยให้เป็นโมฆะอย่างสมบูรณ์ แน่นอนว่าคุณจะพบว่าบางแง่มุมไม่ตรงกับความต้องการของคุณและคุณอาจรู้สึกว่าจำเป็นต้องตั้งโครงสร้างรอบหุ่นกระบอก

ในทางตรงกันข้ามแชปลินเพ่งความสนใจไปที่แอพ Backbone ที่ค่อนข้างเล็ก แต่สำคัญมากนั่นคือโครงสร้างแอพโดยรวมและวงจรชีวิตของโมดูล ในเรื่องนี้แชปลินเป็น opionated มากและเป็นเหมือนกรอบกว่าห้องสมุด (เช่นใน "รหัสของคุณเรียกห้องสมุด, กรอบเรียกรหัสของคุณ") แชปลินมีคลาสกลางบางคลาสที่อยู่เหนือโมดูลแอปพลิเคชันแต่ละตัวและควบคุมสถานะแอปโดยรวม สิ่งนี้ทำให้แอปของคุณมีโครงสร้างทั่วไปเช่น Ruby on Rails เป็นตัวอย่าง

ในแชปลินคุณประกาศเส้นทางบางเส้นทางที่แมปไปยังตัวควบคุมและแชปลินเริ่มตัวควบคุมเมื่อเส้นทางตรงกัน นอกจากนี้ยังดูแลการกำจัดตัวควบคุมเก่าและการแสดงและการซ่อนมุมมองหลักซึ่งควรจะสร้างตัวควบคุม นี่เป็นแนวคิดพื้นฐาน แต่แชปลินดูแลรายละเอียดที่น่าเกลียดเพื่อให้การดำเนินการนี้ราบรื่น

มีสองหลักการที่มาพร้อมกับโครงสร้างนี้: - การทำให้เป็นโมดูล, การแยกและการแซนด์บ็อกซ์ - การสื่อสารข้ามโมดูลโดยใช้การเผยแพร่ / สมัครสมาชิกและผู้ไกล่เกลี่ย

แน่นอนว่ารูปแบบเหล่านี้ไม่ใช่ของใหม่ในโลกการพัฒนาซอฟต์แวร์และ Chaplin ไม่ใช่ห้องสมุดเพียงแห่งเดียวที่ใช้กับแอป Backbone.js

แชปลินยังให้การปรับปรุงสำหรับเลเยอร์มุมมองเช่น CollectionView ที่มีความซับซ้อนสูง แต่โดยรวมแล้วไม่มากเท่ากับหุ่นกระบอกที่มีภูมิภาคและเลย์เอาต์ แต่มันค่อนข้างง่ายที่จะเขียนคลาสเมตาดังกล่าวโดยใช้วิธีการที่ Chaplin Views จัดให้

เฟรมเวิร์กส่วนใหญ่ (ทั้งหมด) ที่คุณกำลังมองหาแก้ปัญหาเดียวกัน แต่พวกเขาทำในรูปแบบที่แตกต่างกันเล็กน้อยโดยมีเป้าหมายแตกต่างกันเล็กน้อย

ฉันคิดว่ามันยุติธรรมที่จะบอกว่าโครงการเหล่านี้ทั้งหมดจะแก้ปัญหาในประเภทเหล่านี้:

• ระบุชุดค่าเริ่มต้นที่สมเหตุสมผล
• ลดรหัสสำเร็จรูป
• จัดเตรียมโครงสร้างแอปพลิเคชันที่ด้านบนของโครงสร้างบล็อก BackboneJS
• แยกรูปแบบที่ผู้เขียนใช้ในแอพ

หุ่นกระบอกซึ่งฉันสร้างมาตั้งแต่เดือนธันวาคม 2554 มีเป้าหมายและอุดมคติที่แตกต่างกันอยู่สองสามประการเช่นกัน:

• สถาปัตยกรรมแอปพลิเคชันแบบรวม
• รูปแบบการส่งข้อความขององค์กรมีอิทธิพล
• ตัวเลือกการทำให้เป็นโมดูล
• การใช้งานที่เพิ่มขึ้น (ไม่มีข้อกำหนดทั้งหมดหรือไม่มีเลย)
• ไม่มีการล็อคอินเซิร์ฟเวอร์
• ทำให้ง่ายต่อการเปลี่ยนค่าเริ่มต้นเหล่านั้น
• รหัสเป็นการกำหนดค่า / การกำหนดค่ามากกว่า

ฉันไม่ได้บอกว่ากรอบอื่น ๆ ไม่มีเป้าหมายเดียวกันนี้ แต่ฉันคิดว่าเอกลักษณ์ของมาริโอเน็ตต์มาจากการผสมผสานของเป้าหมายเหล่านี้

สถาปัตยกรรมแอพลิเคชันคอมโพสิต

ฉันใช้เวลามากกว่า 5 ปีในการทำงานกับไคลเอนต์หนาระบบซอฟต์แวร์แบบกระจายโดยใช้ WinForms และ C # ฉันสร้างแอพสำหรับเดสก์ท็อปแล็ปท็อป (ไคลเอนต์สมาร์ท) อุปกรณ์มือถือและเว็บแอปพลิเคชันทั้งหมดแบ่งปันชุดฟังก์ชั่นหลักและทำงานกับเซิร์ฟเวอร์เดียวกันแบ็คเอนด์หลายครั้ง ในเวลานี้ฉันเรียนรู้คุณค่าของการทำให้เป็นโมดูลและย้ายไปอย่างรวดเร็วในเส้นทางของการออกแบบแอพพลิเคชั่นคอมโพสิต

แนวคิดพื้นฐานคือ "เขียน" ประสบการณ์รันไทม์ของแอปพลิเคชันของคุณและประมวลผลจากชิ้นส่วนเล็ก ๆ ที่ไม่จำเป็นต้องรู้ซึ่งกันและกัน พวกเขาลงทะเบียนตัวเองกับระบบแอปพลิเคชันโดยรวมแล้วพวกเขาก็สื่อสารผ่านวิธีการต่าง ๆ ของข้อความแยกและการโทร

ฉันได้เขียนเล็กน้อยเกี่ยวกับสิ่งนี้ในบล็อกของฉันแนะนำ Marionette เป็นสถาปัตยกรรมแอปพลิเคชันแบบรวมสำหรับ Backbone:

• http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/

คิวข้อความ / รูปแบบ

ระบบกระจายแบบกระจายขนาดใหญ่เดียวกันก็ใช้ประโยชน์จากการจัดคิวข้อความรูปแบบการรวมองค์กร (รูปแบบการส่งข้อความ) และบัสบริการเพื่อจัดการกับข้อความ สิ่งนี้มีอิทธิพลอย่างมากต่อแนวทางการพัฒนาซอฟต์แวร์ของฉัน ฉันเริ่มเห็นแอปพลิเคชั่น WinForms ในหน่วยประมวลผลเดียวจากมุมมองนี้และในไม่ช้าการพัฒนาด้านเซิร์ฟเวอร์และแอปพลิเคชันเว็บของฉันก็ได้รับอิทธิพลจากสิ่งนี้

สิ่งนี้ได้แปลโดยตรงไปยังวิธีที่ฉันดูการออกแบบแอปพลิเคชันของ Backbone ฉันให้ตัวรวบรวมเหตุการณ์ใน Marionette สำหรับทั้งแอปพลิเคชันระดับสูงและสำหรับแต่ละโมดูลที่คุณสร้างภายในแอปพลิเคชัน

ฉันคิดถึงข้อความที่ฉันสามารถส่งระหว่างโมดูลได้: ข้อความคำสั่งข้อความเหตุการณ์และอื่น ๆ ฉันยังคิดถึงการสื่อสารด้านเซิร์ฟเวอร์เป็นข้อความที่มีรูปแบบเดียวกันนี้ รูปแบบบางอย่างได้เข้ามาใน Marionette แล้ว แต่ก็ยังไม่มี

• http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
• http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
• http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (รหัส WinForms แต่ยังใช้ได้)

modularization

การทำให้เป็นโมดูลของโค้ดนั้นมีความสำคัญอย่างมาก การสร้างแพคเกจขนาดเล็กที่ห่อหุ้มอย่างดีซึ่งมีโฟกัสเอกพจน์พร้อมจุดเข้า - ออกที่กำหนดไว้อย่างดีเป็นสิ่งจำเป็นสำหรับระบบใด ๆ ที่มีขนาดและความซับซ้อนที่สำคัญ

Marionette นำเสนอการทำให้เป็นโมดูลโดยตรงผ่านmoduleคำจำกัดความของมัน แต่ฉันก็จำได้ว่าบางคนชอบ RequireJS และต้องการใช้สิ่งนั้น ดังนั้นฉันจึงให้ทั้งบิลด์มาตรฐานและบิลด์ที่เข้ากันได้กับ RequireJS

MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(ยังไม่มีการโพสต์บล็อกสำหรับสิ่งนี้)

การใช้งานที่เพิ่มขึ้น

นี่คือหนึ่งในปรัชญาหลักที่ฉันอบเข้าไปในส่วนต่างๆของหุ่นกระบอกที่ฉันทำได้: ไม่มีข้อกำหนด "ทั้งหมด - หรือ - ไม่มี" สำหรับการใช้หุ่นกระบอก

Backbone นั้นใช้วิธีการที่เพิ่มมากขึ้นและเป็นแบบแยกส่วนกับวัตถุของบล็อกทั้งหมด คุณมีอิสระที่จะเลือกสิ่งที่คุณต้องการใช้เมื่อใด ฉันเชื่อมั่นอย่างยิ่งในหลักการนี้และพยายามทำให้แน่ใจว่า Marionette ทำงานในลักษณะเดียวกัน

ด้วยเหตุนี้ชิ้นส่วนใหญ่ที่ฉันได้สร้างในหุ่นกระบอกจะถูกสร้างขึ้นเพื่อยืนอยู่คนเดียวทำงานกับแกนหลักของ Backbone และทำงานร่วมกันได้ดียิ่งขึ้น

ตัวอย่างเช่นแอปพลิเคชัน Backbone เกือบทุกตัวต้องแสดงมุมมอง Backbone แบบไดนามิกในสถานที่เฉพาะบนหน้าจอ แอพจำเป็นต้องจัดการกับการปิดมุมมองเก่าและล้างหน่วยความจำเมื่อมีการสร้างใหม่ นี่คือสิ่งที่ Marionette เข้าRegionมาเล่น ภูมิภาคจัดการกับรหัสสำเร็จรูปของการดูเรียกการแสดงผลและการบรรจุผลใน DOM สำหรับคุณ จากนั้นจะปิดมุมมองนั้นและล้างข้อมูลให้คุณหากมุมมองของคุณมีวิธี "ปิด"

MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

แต่คุณไม่จำเป็นต้องใช้มุมมองของ Marionette เพื่อใช้พื้นที่ ข้อกำหนดเพียงอย่างเดียวคือคุณกำลังขยายจาก Backbone ดูในบางจุดในห่วงโซ่ต้นแบบของวัตถุ หากคุณเลือกที่จะให้closeวิธีการonShowวิธีการหรือภูมิภาคอื่น ๆ ของ Marionette จะโทรหาคุณในเวลาที่เหมาะสม

• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
• http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

ไม่มีเซิร์ฟเวอร์ล็อคอิน

ฉันสร้างแอป Backbone / Marionette บนเทคโนโลยีเซิร์ฟเวอร์ที่หลากหลาย:

• ASP.NET MVC
• ทับทิมบนราง
• ทับทิม / ซินาตร้า
• NodeJS / ExpressJS
• PHP / Slim
• ชวา
• Erlang
• ... และอื่น ๆ

JavaScript คือ JavaScript เมื่อมีการเรียกใช้ในเบราว์เซอร์ JavaScript ฝั่งเซิร์ฟเวอร์นั้นยอดเยี่ยมเช่นกัน แต่ไม่มีผลกระทบหรือไม่มีอิทธิพลต่อวิธีที่ฉันเขียน JavaScript ตามเบราว์เซอร์

เนื่องจากความหลากหลายในโครงการที่ฉันสร้างและเทคโนโลยีแบ็คเอนด์ที่ลูกค้าของฉันใช้ฉันไม่สามารถและจะไม่ล็อค Marionette เข้ากับเทคโนโลยีกองเซิร์ฟเวอร์ฝั่งเดียวด้วยเหตุผลใดก็ตาม ฉันจะไม่ให้โครงการสำเร็จรูป ฉันจะไม่ให้พลอยทับทิมหรือแพ็คเกจ npm ฉันต้องการให้คนเข้าใจว่า Marionette ไม่ต้องการเซิร์ฟเวอร์ด้านหลังเฉพาะ มันเป็น JavaScript ที่ใช้เบราว์เซอร์และส่วนแบ็คเอนด์ก็ไม่สำคัญ

แน่นอนฉันสนับสนุนผู้อื่นอย่างเต็มที่ในการจัดหาแพ็คเกจสำหรับภาษาและกรอบงาน ฉันแสดงรายการแพ็คเกจเหล่านั้นใน Wiki และหวังว่าผู้คนจะสร้างแพ็คเกจต่อไปตามที่เห็นว่าจำเป็น แต่นั่นคือการสนับสนุนจากชุมชนไม่ใช่การสนับสนุนโดยตรงจากหุ่นเชิด

• https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

เปลี่ยนค่าเริ่มต้นได้อย่างง่ายดาย

ในความพยายามของฉันเพื่อลดรหัสต้นแบบและให้ค่าเริ่มต้นที่สมเหตุสมผล (ซึ่งเป็นความคิดที่ว่าฉัน "ยืม" โดยตรงจาก LayoutManager ของ Tim Branyen) ฉันยอมรับความต้องการของนักพัฒนาอื่น ๆ ที่จะใช้การใช้งานที่แตกต่างกันเล็กน้อยกว่าที่ฉันทำ

ฉันให้การแสดงผลตาม<script>แท็กอินไลน์สำหรับเทมเพลตโดยใช้ Underscore.js templating เป็นค่าเริ่มต้น แต่คุณสามารถแทนที่สิ่งนี้ได้โดยการเปลี่ยนRendererและ / หรือTempalteCacheวัตถุในหุ่นกระบอก วัตถุทั้งสองนี้เป็นแกนหลักของความสามารถในการแสดงผลและมีหน้าวิกิที่แสดงวิธีการเปลี่ยนแปลงสิ่งนี้สำหรับเอ็นจิ้นการสร้างเทมเพลตเฉพาะและวิธีการโหลดเทมเพลตที่แตกต่างกัน

ด้วย v0.9 ของ Marionette มันจะง่ายขึ้นกว่าเดิม ตัวอย่างเช่นหากคุณต้องการแทนที่การใช้บล็อกสคริปต์เทมเพลตแบบอินไลน์ด้วยเทมเพลตที่รวบรวมไว้ล่วงหน้าคุณจะต้องแทนที่หนึ่งวิธีใน Renderer เท่านั้น:

Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

และตอนนี้แอปพลิเคชันทั้งหมดจะใช้เทมเพลตที่รวบรวมไว้ล่วงหน้าซึ่งคุณแนบไปกับtemplateแอตทริบิวต์ของมุมมองของคุณ

ฉันยังมี Add-on ของ Marionette ด้วย Async กับ v0.9 ที่ให้คุณสนับสนุนมุมมองการเรนเดอร์แบบอะซิงโครนัส ฉันพยายามอย่างต่อเนื่องที่จะทำให้มันง่ายที่สุดเท่าที่จะทำได้เพื่อแทนที่พฤติกรรมเริ่มต้นในหุ่นกระบอก

รหัสเป็นการกำหนดค่า

ฉันเป็นแฟนตัวยงของ "การประชุมเรื่องการกำหนดค่า" ในบางบริบท มันเป็นวิธีที่ทรงพลังในการทำสิ่งต่างๆให้สำเร็จและ Marionette ให้สิ่งนี้เล็กน้อย - แม้ว่าจะไม่มากเกินไปโดยสุจริต เฟรมเวิร์กอื่น ๆ อีกมากมาย - โดยเฉพาะ LayoutManager - ให้การประชุมมากกว่าการตั้งค่ามากกว่าที่ Marionette ทำ

สิ่งนี้ทำโดยมีจุดประสงค์และความตั้งใจ

ฉันสร้างปลั๊กอินเฟรมเวิร์กส่วนเสริมและแอปพลิเคชัน JavaScript ให้เพียงพอเพื่อทราบถึงความเจ็บปวดในการพยายามจัดระเบียบเพื่อให้ทำงานได้อย่างมีความหมายและรวดเร็ว มันสามารถทำได้ด้วยความเร็ว แต่โดยทั่วไปแล้วจะมีความสามารถในการเปลี่ยนแปลง

ด้วยเหตุนี้ฉันจึงใช้วิธี "รหัสเป็นการกำหนดค่า" กับหุ่นกระบอก ฉันไม่มี API "การกำหนดค่า" จำนวนมากที่คุณสามารถจัดเตรียมวัตถุตามตัวอักษรด้วยค่าคงที่ที่เปลี่ยนแนวพฤติกรรม แต่ฉันทำเอกสารวิธีการที่แต่ละวัตถุมี - ทั้งผ่านซอร์สโค้ดที่มีคำอธิบายประกอบและผ่านเอกสาร API จริง - ด้วยความตั้งใจที่จะบอกคุณว่าจะเปลี่ยนหุ่นกระบอกให้ทำงานตามที่คุณต้องการ

โดยการให้ API ที่สะอาดและชัดเจนสำหรับวัตถุ Marionette ฉันสร้างสถานการณ์ที่แทนที่พฤติกรรมของวัตถุเฉพาะหรือ Marionette โดยรวมนั้นค่อนข้างง่ายและยืดหยุ่นมาก ฉันเสียสละการกำหนดค่า API แบบ "ง่าย" เพื่อความยืดหยุ่นในการให้รหัสของคุณเองเพื่อให้สิ่งต่าง ๆ ทำงานได้อย่างที่คุณต้องการ

คุณจะไม่พบ API "กำหนดค่า" หรือ "ตัวเลือก" ในหุ่นกระบอก แต่คุณจะพบว่ามีวิธีการมากมายที่แต่ละจุดให้บริการมีจุดประสงค์ที่เฉพาะเจาะจงมากด้วยลายเซ็นที่สะอาดซึ่งทำให้ง่ายต่อการเปลี่ยนวิธีการทำงานของหุ่นกระบอก

ขณะนี้ฉันกำลังใช้แบ็คโบนกับโมดูลตัวจัดการเลย์เอาต์และแฮนด์บาร์เป็นเครื่องมือสร้างแรงบันดาลใจและฉันพบว่าการติดตั้งแอปพลิเคชั่นเล็ก ๆ น้อย ๆ ได้อย่างง่ายดายโดยใช้แบ็กเอนด์ Grails ที่มีอยู่แล้ว ก่อนที่จะเริ่มใช้ตัวจัดการเลย์เอาท์ฉันอ่านเกี่ยวกับ Marionette และแชปลินและทั้งคู่ดูเหมือนฉันจะทรงพลัง แต่ซับซ้อน จากนั้นฉันก็จำได้ว่าทำไมฉันถึงเลือก backbone.js: ความเรียบง่าย เฟรมเวิร์กเหล่านี้เพิ่มสิ่งที่กระดูกสันหลังออกจากการออกแบบ ฉันไม่ได้บอกว่ากรอบงานไม่ดี แต่ถ้าฉันต้องการอะไรที่ซับซ้อนกว่านี้ฉันจะลองทำโปรเจ็กต์อื่น ๆ เช่น ember.js หรือ sproutcore เนื่องจากมันมี codebase ที่ไม่ซ้ำใครเขียนโดยมีเป้าหมายอยู่ในใจของนักพัฒนา ที่นี่เรามีกรอบอยู่ด้านบนของอีกคนหนึ่ง แน่นอนว่ากระดูกสันหลังเป็นกระดูกสันหลังไม่เพียง แต่สำหรับการสร้างแอปพลิเคชัน แต่ยังสำหรับการเขียนห้องสมุดที่มีประสิทธิภาพมากขึ้น แต่สิ่งเดียวที่ฉันคิดว่าแย่จริงๆคือเป็นเลเยอร์มุมมองเนื่องจากไม่มีตัวจัดการเลย์เอาต์และความเป็นไปได้ในการซ้อนมุมมอง ด้วยเครื่องมือจัดการเลย์เอาท์ที่เติมเต็มช่องว่างได้ค่อนข้างดี

ดังนั้นคำตอบสำหรับคำถามของคุณคือ: เริ่มต้นจากการใช้กระดูกสันหลังและถามตัวคุณเองว่าอะไรที่หายไปและสิ่งที่คุณคาดหวังเกี่ยวกับกรอบ หากคุณพบว่ามีหลายสิ่งที่เหลืออยู่โดยกระดูกสันหลังออกไปแล้วค้นหาสิ่งเหล่านี้ในกรอบอื่น ๆ และเลือกสิ่งที่ใกล้เคียงกับความต้องการของคุณ และถ้าคุณยังไม่มั่นใจในตัวเลือกบางทีกระดูกสันหลังอาจไม่เหมาะกับคุณและคุณต้องหาวิธีแก้ปัญหาอื่น (ember.js, sproutcore, ExtJs, JavaScript MVC นั้นดีทั้งหมด) หากคุณมีประสบการณ์ในการเขียนแอพไคลเอนต์คุณไม่จำเป็นต้องมีประสบการณ์ในกรอบการทำงานทั้งหมดเพื่อเลือกแอปที่เหมาะสม (สำหรับคุณแน่นอน)

ฉันได้ศึกษากรอบต่าง ๆ ที่สร้างขึ้นด้วย Backbone.js และสร้าง Vertebrae สำหรับโครงการที่ HauteLook เป้าหมายของโครงการรวมถึง: การโหลดสคริปต์แบบไดนามิก, รูปแบบโมดูลของ AMD, การจัดการการพึ่งพา, สร้างด้วยไลบรารีโอเพ่นซอร์สส่วนใหญ่, จัดระเบียบโค้ดในแพ็คเกจ, ปรับแต่งและสร้างสำหรับแอพพลิเคชั่นหน้าเดียวหนึ่งหรือหลายโฮสต์บนเซิร์ฟเวอร์แคชทั้งหมดเช่นไม่มีเซิร์ฟเวอร์ - สคริปต์ด้านข้างใช้เพียง API สำหรับข้อมูลและที่สนุกที่สุดสำหรับฉันใช้การพัฒนาพฤติกรรมที่ขับเคลื่อนด้วยโครงการ มีคำอธิบายเกี่ยวกับโครงการที่: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

ปัญหาของเรา:

ไลบรารีที่เลือก (jQuery, Underscore.js, Backbone.js, RequireJS, หนวด) ให้การโหลดโมดูลการจัดการการพึ่งพาโครงสร้างแอปพลิเคชัน (สำหรับโมเดลคอลเลกชันมุมมองและเส้นทาง) การโต้ตอบแบบอะซิงโครนัสกับ API ยูทิลิตี้และวัตถุต่างๆ เช่น (สัญญา) รอการตัดบัญชีโทรกลับ ตรรกะที่เหลืออยู่ที่จำเป็นในการทำเฟรมเวิร์กประกอบด้วย:

• วัตถุ (รุ่น) เพื่อจัดการสถานะของแอปพลิเคชันหน้าเดียว;
• เครื่องมือจัดการโครงร่างที่จะนำเสนอจัดเรียง / เปลี่ยนแปลงและมุมมองที่ชัดเจนและ
• คอนโทรลเลอร์ที่ตอบสนองต่อเส้นทางรับ / กำหนดสถานะแอปพลิเคชันและมอบงานให้กับผู้จัดการเลย์เอาต์

โซลูชั่นของเรา (ดำเนินการใน Vertebrae):

Application State Manager -

ตัวจัดการแอปพลิเคชันเก็บข้อมูลในหน่วยความจำและยังคงข้อมูลในที่จัดเก็บเบราว์เซอร์เพื่อให้ทรัพยากรสำหรับข้อมูลทั่วไป / เมตาดาต้า ให้ข้อมูล (สถานะ) เพื่อสร้างการดูหน้าเว็บใหม่ตามการโต้ตอบก่อนหน้า (เช่นแท็บที่เลือกตัวกรองที่ใช้) ตัวจัดการสถานะแอปพลิเคชันจัดเตรียมกลยุทธ์สำหรับทรัพยากรในการเรียกข้อมูลสถานะ หมายถึงทำหน้าที่เป็นเครื่องรัฐ

เครื่องมือจัดการเค้าโครง -

ตัวจัดการโครงร่างมีมุมมองหนึ่งหรือหลายมุมมองรวมถึงปลายทางเอกสาร (DOM) สำหรับแต่ละมุมมอง (แสดงผล) หน้าอาจเปลี่ยนระหว่างมุมมองหลายมุมมองดังนั้นตัวจัดการโครงร่างจะติดตามสถานะมุมมองเช่นแสดงผลไม่แสดงผลแสดงไม่แสดง คุณสามารถใช้ตัวจัดการโครงร่างเพื่อปล่อยมุมมองและเรนเดอร์ (แบบแยกส่วน) ที่ผู้เข้าชมไซต์มีแนวโน้มที่จะร้องขอเช่นการเปลี่ยนแท็บในหน้า การเปลี่ยนแปลงระหว่างสถานะมุมมองถูกจัดการโดยวัตถุนี้ เลย์เอาต์ทั้งหมดอาจถูกล้างเพื่อให้มุมมองวัตถุและการเชื่อมโยงถูกลบออกเตรียมวัตถุเหล่านี้เพื่อรวบรวมขยะ (ป้องกันการรั่วไหลของหน่วยความจำ) ตัวจัดการโครงร่างยังสื่อสารสถานะมุมมองกับคอนโทรลเลอร์

คอนโทรลเลอร์ -

วัตถุตัวควบคุมถูกเรียกใช้โดยฟังก์ชั่นตัวจัดการเส้นทางและรับผิดชอบในการรับสถานะที่เกี่ยวข้อง (รุ่นของแอปพลิเคชัน) เพื่อสร้างหน้า (รูปแบบ) (รับผิดชอบการตั้งค่าสถานะเมื่อเปลี่ยนเส้นทาง) ตัวควบคุมจะส่งผ่านข้อมูลที่ขึ้นอยู่กับ (โมเดล / คอลเลกชัน) และสร้างวัตถุมุมมองสำหรับหน้าที่ร้องขอไปยังตัวจัดการโครงร่าง ในฐานะที่เป็นผลข้างเคียงการใช้ตัวควบคุมป้องกันไม่ให้วัตถุเส้นทางเกิดการพองตัวและพันกัน เส้นทางควรแมปไปยังตัวควบคุมซึ่งจะเปิดปิดการดูหน้าเว็บทำให้ฟังก์ชันการจัดการเส้นทางไม่ทำงาน

แอพ Todos โฮสต์ทั้งในโหมด dev และปรับให้เหมาะสมกับ Heroku ...

• http://vertebrae-framework.herokuapp.com/
• http://vertebrae-optimized.herokuapp.com/

แนวคิดจำนวนมากในเฟรมเวิร์กอื่น ๆ ถูกยืมเช่นความต้องการที่จะทำลายมุมมองเพื่อดูตัวอย่างการรั่วไหลของหน่วยความจำตามที่ Derick Bailey ระบุ - http://lostechies.com/derickbailey/ ; ผู้จัดการเลย์เอาต์โดย Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

โดยสรุป Backbone.js มีความหมายว่าเป็นเครื่องมือในแอปพลิเคชันของคุณไลบรารี Backbone.js ไม่ได้จัดเตรียมสถาปัตยกรรมทั้งหมดที่คุณจะต้องสร้างแอปพลิเคชัน แต่ให้การโต้ตอบที่ดีกับ API และโครงสร้างโค้ดที่มั่นคงสำหรับ ... มุมมอง (ทำหน้าที่เป็นผู้ควบคุมด้วย) และโมเดลเลเยอร์และคอลเลกชันของคุณและสุดท้ายเส้นทาง เราสร้าง Vertebrae เพื่อบรรลุเป้าหมายของโครงการของเราและตัดสินใจที่จะแยกรหัสเป็นกรอบสำหรับให้ผู้อื่นใช้เรียนรู้หรืออะไรก็ตาม

คำตอบสำหรับคำถามของคุณในความคิดของฉันคือการเรียนรู้จากกรอบการทำงานทั้งหมดและใช้สิ่งที่คุณต้องการเพื่อให้บรรลุเป้าหมายของคุณหากคุณพบว่าเป้าหมายโครงการของคุณสอดคล้องกับกรอบงานที่สร้างด้วย Backbone อย่างยอดเยี่ยม มีตัวอย่างที่ยอดเยี่ยมที่ชุมชนแบ่งปัน หรือหากคุณพบว่าตัวเองหลงทางในการสมัครของคุณให้เลือกสิ่งที่ให้ความเห็นมากกว่าและมีโครงสร้างบางทีอาจจะเป็น Ember.js สิ่งที่ดีคือมีตัวเลือกที่หลากหลายเพื่อช่วยให้คุณใช้รหัส (MVX) MVC เช่นรูปแบบกับ JavaScript

ฉันพัฒนากรอบ Lucaในขณะที่ทำงานที่ BenchPrep ซึ่งเราใช้มันเพื่อพัฒนาแอพพลิเคชั่นหน้าเดียวขนาดใหญ่หลายตัวที่ด้านบนของไลบรารี backbone.js

ฉันเคยทำงานกับ ExtJS มาหลายปีแล้วและได้ขโมยแนวคิดที่ฉันโปรดปรานจากเฟรมเวิร์กนั้นเช่นสถาปัตยกรรมที่ขับเคลื่อนด้วยส่วนประกอบซึ่งคุณพัฒนามุมมองของคุณเป็นองค์ประกอบแบบสแตนด์อโลนแล้วรวมเข้ากับส่วนประกอบอื่น ๆ โดยใช้มุมมองคอนเทนเนอร์ และเนื่องจากมันขึ้นอยู่กับการกำหนดค่าเป็นอย่างมากการพัฒนาแอปใน Luca จึงรู้สึกเหมือนอธิบายวัตถุด้วย JSON

ข้อดีอย่างหนึ่งของวิธีการนี้คือความสามารถในการนำส่วนประกอบมาใช้ซ้ำในหลาย ๆ แอพหรือในที่ต่าง ๆ ในแอพของคุณโดยมีการเปลี่ยนแปลงเพียงเล็กน้อยโดยใช้ส่วนขยายของ Backbone นอกจากนี้ยังง่ายต่อการทดสอบกับโครงร่าง / งานนำเสนอที่หลากหลายของส่วนประกอบโดยทำการปรับแต่งเล็กน้อยกับการกำหนดค่า JSON

นอกเหนือจากฟังก์ชั่นผู้ช่วย / ยูทิลิตี้หลากหลายแล้ว Luca Ships ยังมี Backbone ในระดับที่สูงกว่าซึ่งคุณสามารถรวมเข้าด้วยกันได้ทุกวิถีทางเพื่อจินตนาการถึงการสร้าง UI ที่ซับซ้อน

มุมมองส่วนประกอบส่วนประกอบ

• Augmented Model, View, Collection, คลาสเราเตอร์
• ตัวเลือกการกำหนดค่าที่อำนวยความสะดวกในการสื่อสารระหว่างรุ่นคอลเลกชันมุมมองแอปพลิเคชันและผู้จัดการที่เกี่ยวข้อง
• ตู้คอนเทนเนอร์ (เค้าโครงแบบแยก / คอลัมน์, เค้าโครงกริด, มุมมองแท็บ, มุมมองการ์ด / ตัวช่วยสร้าง)
• FormView พร้อมกับส่วนประกอบฟิลด์มาตรฐานทั้งหมดและผู้ช่วยเหลือสำหรับการซิงค์กับ Backbone.Model
• GridView สำหรับสร้างองค์ประกอบกริดแบบเลื่อนได้จาก Luca.Collection
• CollectionView สำหรับการสร้างมุมมองตามคอลเลกชัน
• แถบเครื่องมือ / ปุ่ม

Twitter Bootstrap สไตล์และมาร์กอัปฟรี

• Luca เล่นได้ดีมากกับเฟรมเวิร์ก bootstrap ของ Twitter เพียงแค่ตั้งค่า Luca.enableBootstrap = true และรวมถึง CSS ส่วนประกอบของคุณ (เช่นมุมมองแท็บแถบเครื่องมือปุ่มรูปแบบเขตข้อมูลกริด ฯลฯ ) จะใช้มาร์กอัปที่เข้ากันได้กับ Twitter Bootstrap และการประชุม CSS คลาสโดยอัตโนมัติ
• ใช้ระบบกริดสำหรับการจัดวางและตอบสนองกับ bootstrap base css คลาสส่วนใหญ่ด้วยวิธีที่ชาญฉลาด
• ส่วนประกอบ Luca.Viewport และ GridLayout ได้รับการตั้งค่าให้ทำงานกับระบบกริดแบบตอบสนองของเหลวหรือสแตติกของ bootstrap
• มีวัตถุประสงค์เพื่อจัดให้มีการแข่งขันแบบหนึ่งต่อหนึ่งสำหรับส่วนประกอบ twitter bootstrap เพื่อแสดงเป็น Backbone Views ที่กำหนดค่าได้

องค์ประกอบของแอปพลิเคชัน

• เครื่องรัฐตาม Backbone.Model ให้วิธี getter / setter และเหตุการณ์การเปลี่ยนแปลงคุณสมบัติเป็นรูปแบบของการไหลของการควบคุมแอพลิเคชัน
• ส่วนประกอบคอนโทรลเลอร์แบบรวมที่ซ่อน / แสดงหน้าของแอพเพื่อตอบสนองต่อเหตุการณ์ Backbone.Router หรือ State Machine
• Integrated Collection Manager ซึ่งติดตามคอลเล็กชันที่คุณสร้างอนุญาตให้คุณกำหนดขอบเขตจัดกลุ่มจัดกลุ่มกำหนดพารามิเตอร์เริ่มต้นให้กับพวกเขา
• ตัวจัดการซ็อกเก็ตซึ่งเป็นเลเยอร์นามธรรมที่อยู่ด้านบนของบริการ websocket ที่ทำให้การกดเป็นเรื่องง่ายเหมือน Backbone
• Keyboard Event เร้าเตอร์ที่เรียกชื่อเหตุการณ์สำคัญในส่วนประกอบที่สนใจตอบสนองต่อเหตุการณ์ดังกล่าว

การปรับปรุงการรวบรวมและแบบจำลอง

• คอลเลกชันจะขึ้นอยู่กับกระดูกสันหลังแบบสอบถามซึ่งมีอินเตอร์เฟสการสืบค้นคล้ายกับ mongoDb
• เปิดใช้งานที่เก็บข้อมูลในเครื่อง Backbone.sync เพียงแค่ตั้งค่า collection.localStorage = true
• การรวบรวมข้อมูลโดยอัตโนมัติของคอลเล็กชันที่มีข้อมูลถูก bootstrapped เมื่อโหลดหน้าเว็บ
• วิธีการแคช / คุณสมบัติการคำนวณ แคชผลลัพธ์ของเมธอดการรวบรวมและหมดอายุแคชเพื่อตอบสนองต่อการเปลี่ยนแปลง / เพิ่ม / ลบเหตุการณ์บนคอลเล็กชันหรือโมเดล
• คุณสมบัติที่คำนวณได้ในโมเดล สร้างคุณลักษณะตามฟังก์ชันที่ซับซ้อนและอัปเดตค่าที่คำนวณโดยอัตโนมัติเพื่อตอบสนองต่อการเปลี่ยนแปลง

กิจกรรมและเบ็ด

องค์ประกอบ Luca มีอิสระมากขึ้นกับเหตุการณ์ที่ปล่อยออกมาเมื่อเปรียบเทียบกับส่วนประกอบ Backbone ของสต็อค พวกเขาจะปล่อยเหตุการณ์เช่นก่อน: เริ่มต้นหลังจาก: เริ่มต้นก่อน: แสดงผลหลังจาก: แสดงผลเปิดใช้งานก่อน: เปิดใช้งานปิดการใช้งานครั้งแรก: ปิดการใช้งานและสิ่งนี้ช่วยให้คุณปรับพฤติกรรมของส่วนประกอบของคุณ นอกจากนี้โดยการกำหนดกิจกรรมใน @hooks porperty ในมุมมองของคุณมันจะเรียกฟังก์ชันที่มีชื่อคล้ายกันโดยอัตโนมัติหากมีอยู่ นี่เป็นการป้องกันโค้ดสไตล์การโทรกลับจำนวนมาก

คุณยังสามารถกำหนดค่าคลาส Luca.Events เพื่อเผยแพร่เหตุการณ์ไปยังช่องทางเผยแพร่ / สมัครสมาชิกทั่วโลกซึ่งทำให้การสร้างแอปพลิเคชันขนาดใหญ่ง่ายขึ้นและช่วยในการสื่อสารระหว่างโมดูล

อัญมณีทับทิม

Luca ได้รับการพัฒนาโดยเฉพาะในขณะที่ทำงานกับ Rails และ Sinatra API และเนื่องจากสิ่งนี้ได้รับการปรับให้เหมาะสมสำหรับกองซ้อนที่เฉพาะเจาะจง

Luca มาเผยแพร่โดยเป็นส่วนหนึ่งของ Ruby Gem ที่กำหนดค่าให้ทำงานบนไพพ์ไลน์ของสินทรัพย์หรือเป็นไฟล์ JS ที่ดาวน์โหลดได้

คุณไม่จำเป็นต้องใช้ Rails หรือ Sinatra แต่ถ้าคุณทำฉันได้รวมสิ่งที่มีประโยชน์มากมาย

• ไฟล์ที่มีนามสกุล. luca จะถูกประมวลผลเป็น HAML พร้อมการแก้ไขตัวแปรสไตล์ JST (เทียบเท่ากับ. jst.ejs.haml) โดยไปป์ไลน์สินทรัพย์
• ชุดทดสอบสำหรับเบราว์เซอร์หรือชุดทดสอบที่ใช้หัวจัสมินพร้อมกับผู้ช่วยทดสอบ Backbone และ Underscore จำนวนมาก
• API ปลายทางสำหรับชุดเครื่องมือพัฒนาที่มาพร้อมกับ Luca (เพิ่มเติมในภายหลัง)
• API endpoint ที่ช่วยให้คุณใช้ Redis เป็นเอ็นจินการจัดเก็บ schemaless สำหรับ Luca.Collection ด้วยการกำหนดค่าน้อยที่สุด

เครื่องมือในการพัฒนา

• แอปพลิเคชัน Luca สามารถเปิดใช้งานในคอนโซลเบราว์เซอร์ที่มีตัวช่วยและคำสั่งเฉพาะของ Luca ที่ช่วยในการตรวจสอบตรวจสอบการดีบักแอปพลิเคชันและส่วนประกอบของ Luca

• ด้วยความช่วยเหลือของ Rails Gem และโปรแกรมแก้ไขส่วนประกอบของ CodeMirror ของ Luca คุณสามารถแก้ไขซอร์สโค้ดของ Luca Framework รวมถึงส่วนประกอบเฉพาะแอปพลิเคชันโดยตรงในเบราว์เซอร์โดยใช้ Coffeescript คุณจะเห็นความคิดเห็นทันทีเพื่อตอบสนองการแก้ไขของคุณพร้อมกับอินสแตนซ์ของวัตถุที่ได้รับผลกระทบที่ถูกรีเฟรชด้วยต้นแบบที่อัปเดตแล้วและคุณสามารถบันทึกการเปลี่ยนแปลงลงในดิสก์ได้

• Component Tester เป็นแซนด์บ็อกซ์สดสำหรับเล่นกับส่วนประกอบที่ประกอบขึ้นเป็นแอปพลิเคชันของคุณโดยแยกออกจากกัน มันมีเครื่องมือสำหรับการปรับเปลี่ยนต้นแบบของส่วนประกอบการตั้งค่าการพึ่งพาและการกำหนดค่าส่วนประกอบ องค์ประกอบจะแสดงผลใหม่ทันทีทุกครั้งที่คุณทำการแก้ไข คุณสามารถดูและแก้ไขมาร์กอัพที่ส่วนประกอบสร้างรวมถึง CSS โดยตรงในเบราว์เซอร์และดูการเปลี่ยนแปลงของคุณทันที สิ่งนี้ทำให้เป็นเครื่องมือทดลองที่มีค่ามาก

• เครื่องทดสอบส่วนประกอบจะทำงานร่วมกับจัสมินในไม่ช้าเพื่อให้คุณสามารถดูผลลัพธ์ของการทดสอบหน่วยส่วนประกอบของคุณแบบเรียลไทม์เมื่อคุณแก้ไขรหัส

Luca เป็นงานที่อยู่ระหว่างดำเนินการ แต่จะรักษา API ที่เสถียร (ยังไม่ถึง 1.0) และใช้ในแอปที่ใช้งานจริงขนาดใหญ่หลายแห่ง เป็นกรอบการทำงานที่ให้ความเห็นอย่างแน่นอน แต่ฉันพยายามทำให้มันเป็นโมดูลมากขึ้น ฉันกำลังทำงานกับเอกสารและส่วนประกอบตัวอย่าง

ฉันเป็นผู้เขียนร่วมของแชปลินและฉันได้เขียนเปรียบเทียบเชิงลึกระหว่าง Chaplin.js และ Marionette.js:

http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

นี่ไม่ใช่“ จุดโทษ” แต่พยายามอธิบายทั้งสองวิธีด้วยวิธีที่สมดุล