Sebagian besar (semua?) Kerangka yang Anda cari memecahkan masalah yang sama, tetapi mereka melakukannya dengan cara yang sedikit berbeda dengan tujuan yang sedikit berbeda.
Saya pikir adil untuk mengatakan bahwa semua proyek ini akan menyelesaikan masalah dalam kategori ini:
- Berikan serangkaian standar yang masuk akal
- Kurangi kode boilerplate
- Berikan struktur aplikasi di atas blok bangunan BackboneJS
- Ekstrak pola yang digunakan penulis di aplikasi mereka
Marionette, yang telah saya bangun sejak Desember 2011, memiliki beberapa tujuan dan cita-cita yang sangat berbeda, juga:
- Arsitektur aplikasi komposit
- Pengaruh pola olahpesan perusahaan
- Opsi modularisasi
- Penggunaan tambahan (tidak ada persyaratan semua atau tidak sama sekali)
- Tidak ada penguncian server
- Buatlah mudah untuk mengubah default-default itu
- Kode sebagai konfigurasi / konfigurasi berlebih
Saya tidak mengatakan tidak ada kerangka kerja lain yang memiliki tujuan yang sama. Tapi saya pikir keunikan Marionette berasal dari kombinasi tujuan-tujuan ini.
Arsitektur Aplikasi Komposit
Saya menghabiskan lebih dari 5 tahun bekerja di klien-tebal, sistem perangkat lunak terdistribusi menggunakan WinForms dan C #. Saya membuat aplikasi untuk desktop, laptop (smart-client), perangkat seluler dan aplikasi web, semuanya berbagi set fungsional inti dan bekerja dengan server yang sama back-end berkali-kali. Saat ini, saya belajar nilai dari modularisasi dan sangat cepat bergerak ke jalur desain aplikasi komposit.
Ide dasarnya adalah untuk "menyusun" pengalaman runtime aplikasi Anda dan memproses dari banyak potongan kecil yang tidak perlu saling mengenal. Mereka mendaftarkan diri dengan sistem aplikasi komposit keseluruhan dan kemudian mereka berkomunikasi melalui berbagai cara pesan dan panggilan terpisah.
Saya telah menulis sedikit tentang ini di blog saya, memperkenalkan Marionette sebagai arsitektur aplikasi komposit untuk Backbone:
Antrian / Pola Pesan
Skala besar yang sama, sistem terdistribusi juga memanfaatkan antrian pesan, pola integrasi perusahaan (pola pesan), dan bus layanan untuk menangani pesan. Ini, lebih dari segalanya, memiliki pengaruh luar biasa pada pendekatan saya terhadap pengembangan perangkat lunak yang dipisahkan. Saya mulai melihat proses-tunggal, dalam-memori aplikasi WinForms dari perspektif ini, dan segera sisi server saya dan pengembangan aplikasi web mengambil pengaruh dari ini.
Ini secara langsung menerjemahkan bagaimana saya melihat desain aplikasi Backbone. Saya menyediakan agregator acara di Marionette, untuk objek aplikasi tingkat tinggi, dan untuk setiap modul yang Anda buat dalam aplikasi.
Saya berpikir tentang pesan yang dapat saya kirim di antara modul saya: pesan perintah, pesan acara, dan banyak lagi. Saya juga berpikir tentang komunikasi sisi server sebagai pesan dengan pola yang sama. Beberapa pola telah masuk ke Marionette, tetapi beberapa belum.
Modularisasi
Modularisasi kode sangat penting. Membuat paket kecil, enkapsulasi baik yang memiliki fokus tunggal dengan titik masuk dan keluar yang ditentukan dengan baik adalah suatu keharusan bagi sistem apa pun dengan ukuran dan kompleksitas yang signifikan.
Marionette menyediakan modularisasi langsung melalui moduledefinisi itu. Tetapi saya juga mengakui bahwa beberapa orang menyukai RequireJS dan ingin menggunakannya. Jadi saya memberikan build standar dan build yang kompatibel dengan RequireJS.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(Belum ada posting blog untuk ini)
Penggunaan Tambahan
Ini adalah salah satu filosofi inti yang saya gunakan untuk setiap bagian Marionette yang saya dapat: tidak ada persyaratan "semua atau tidak sama sekali" untuk penggunaan Marionette.
Backbone sendiri mengambil pendekatan yang sangat bertahap dan modular dengan semua objek blok pembangunnya. Anda bebas memilih mana yang ingin Anda gunakan, kapan. Saya sangat percaya pada prinsip ini dan berusaha untuk memastikan Marionette bekerja dengan cara yang sama.
Untuk itu, sebagian besar karya yang saya buat untuk Marionette dibangun untuk berdiri sendiri, untuk bekerja dengan potongan-potongan inti dari Backbone, dan untuk bekerja bersama lebih baik lagi.
Sebagai contoh, hampir setiap aplikasi Backbone perlu secara dinamis menampilkan tampilan Backbone di tempat tertentu di layar. Aplikasi juga perlu menangani penutupan tampilan lama dan membersihkan memori ketika yang baru ditempatkan. Di sinilah Marionette Regiondatang untuk bermain. Wilayah menangani kode boilerplate untuk mengambil tampilan, memanggil render di atasnya, dan memasukkan hasilnya ke DOM untuk Anda. Kemudian akan menutup tampilan itu dan membersihkannya untuk Anda, asalkan tampilan Anda memiliki metode "tutup" di atasnya.
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
Tetapi Anda tidak diharuskan untuk menggunakan pandangan Marionette untuk menggunakan suatu wilayah. Satu-satunya persyaratan adalah bahwa Anda memperluas dari Backbone. Lihat di beberapa titik dalam rantai prototipe objek. Jika Anda memilih untuk memberikan closemetode, onShowmetode, atau lainnya, Wilayah Marionette akan memanggilnya untuk Anda pada waktu yang tepat.
Tidak Ada Server Lock-in
Saya membangun aplikasi Backbone / Marionette di atas beragam teknologi server:
- ASP.NET MVC
- Ruby on Rails
- Ruby / Sinatra
- NodeJS / ExpressJS
- PHP / Slim
- Jawa
- Erlang
- ... dan banyak lagi
JavaScript adalah JavaScript, ketika harus dijalankan di browser. JavaScript sisi server juga mengagumkan, tetapi tidak memiliki efek atau pengaruh nol pada cara saya menulis JavaScript berbasis browser.
Karena keragaman dalam proyek yang saya bangun dan teknologi back-end yang digunakan klien saya, saya tidak bisa dan tidak akan mengunci Marionette ke tumpukan teknologi sisi server tunggal untuk alasan apa pun. Saya tidak akan menyediakan proyek boilerplate. Saya tidak akan memberikan permata ruby atau paket npm. Saya ingin orang-orang mengerti bahwa Marionette tidak memerlukan server back-end tertentu. Ini JavaScript berbasis browser, dan back-end tidak masalah.
Tentu saja, saya sepenuhnya mendukung orang lain yang menyediakan paket untuk bahasa dan kerangka kerja mereka. Saya mencantumkan paket-paket itu di Wiki dan berharap orang-orang terus membangun lebih banyak paket sesuai kebutuhan. Tetapi itu adalah dukungan masyarakat, bukan dukungan langsung dari Marionette.
Mudah Mengubah Defaultnya
Dalam upaya saya untuk mengurangi kode boilerplate dan memberikan default yang masuk akal (yang merupakan ide bahwa saya langsung "meminjam" dari Tim Branyen LayoutManager), saya menyadari perlunya pengembang lain untuk menggunakan implementasi yang sedikit berbeda dari yang saya lakukan.
Saya memberikan rendering berdasarkan <script>tag inline untuk templat, menggunakan templat Underscore.js secara default. Tetapi Anda dapat mengganti ini dengan mengubah objek Rendererdan / atau TempalteCachedi Marionette. Dua objek ini menyediakan inti dari kemampuan rendering, dan ada halaman wiki yang menunjukkan cara mengganti ini untuk mesin templating tertentu dan berbagai cara memuat template.
Dengan Marionette v0.9, itu menjadi lebih mudah. Misalnya, jika Anda ingin mengganti penggunaan blok skrip templat inline dengan templat yang sudah dikompilasi sebelumnya, Anda hanya perlu mengganti satu metode di Renderer:
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
dan sekarang seluruh aplikasi akan menggunakan templat yang telah dikompilasi sebelumnya yang Anda lampirkan ke templateatribut tampilan Anda .
Saya bahkan menyediakan add-on Marionette.Async dengan v0.9 yang memungkinkan Anda untuk mendukung tampilan rendering secara tidak sinkron. Saya terus berupaya untuk membuatnya semudah mungkin untuk mengganti perilaku default di Marionette.
Konfigurasi Kode Sebagai
Saya penggemar "konvensi konfigurasi" dalam konteks tertentu. Ini adalah cara yang ampuh untuk menyelesaikan sesuatu, dan Marionette memberikan sedikit ini - meskipun tidak terlalu banyak, jujur. Banyak kerangka kerja lainnya - terutama LayoutManager - memberikan lebih banyak konvensi atas konfigurasi daripada Marionette.
Ini dilakukan dengan maksud dan tujuan.
Saya telah membangun cukup banyak plugin, kerangka kerja, add-on, dan aplikasi JavaScript untuk mengetahui kesulitan mencoba membuat konvensi bekerja dengan cara yang bermakna dan cepat. Ini dapat dilakukan dengan kecepatan, tetapi biasanya dengan biaya untuk mengubahnya.
Untuk itu, saya mengambil pendekatan "kode sebagai konfigurasi" ke Marionette. Saya tidak menyediakan banyak "konfigurasi" API di mana Anda dapat memberikan objek literal dengan nilai statis yang mengubah petak perilaku. Sebagai gantinya, saya mendokumentasikan metode yang dimiliki setiap objek - baik melalui kode sumber beranotasi dan melalui dokumentasi API yang sebenarnya - dengan maksud memberi tahu Anda cara mengubah Marionette agar berfungsi seperti yang Anda inginkan.
Dengan menyediakan API yang bersih dan jelas untuk objek Marionette, saya membuat situasi di mana mengganti perilaku objek tertentu atau Marionette secara keseluruhan relatif sederhana dan sangat fleksibel. Saya mengorbankan konfigurasi API "sederhana" untuk fleksibilitas menyediakan kode Anda sendiri untuk membuat hal-hal bekerja dengan cara yang Anda inginkan.
Anda tidak akan menemukan API "konfigurasi" atau "opsi" di Marionette. Tetapi Anda akan menemukan sejumlah besar metode yang masing-masing melayani tujuan yang sangat spesifik, dengan tanda tangan bersih, yang membuatnya mudah untuk mengubah cara kerja Marionette.
