Baktığınız çerçevelerin çoğu (hepsi?) Aynı sorunları çözüyor, ancak bunu biraz farklı hedeflerle biraz farklı şekillerde yapıyorlar.
Tüm bu projelerin bu kategorilerdeki sorunları çözeceğini söylemek adil olur:
- Makul varsayılanlar kümesi sağlayın
- Isıtıcı plaka kodunu azaltın
- BackboneJS yapı taşlarının üstüne uygulama yapısı sağlayın
- Yazarların uygulamalarında kullandığı kalıpları ayıklayın
Aralık 2011'den bu yana inşa ettiğim Marionette, birkaç farklı hedef ve ideali de göz önünde bulunduruyor:
- Kompozit uygulama mimarisi
- Kurumsal mesajlaşma kalıbı etkisi
- Modülerleştirme seçenekleri
- Artımlı kullanım (ya hep ya hiç gerek yok)
- Sunucu kilitleme yok
- Bu varsayılanları değiştirmeyi kolaylaştırın
- Yapılandırma / aşırı yapılandırma olarak kod
Diğer çerçevelerin hiçbirinin aynı hedeflere sahip olmadığını söylemiyorum. Ama sanırım Marionette'in benzersizliği bu hedeflerin birleşiminden geliyor.
Kompozit Uygulama Mimarisi
WinForms ve C # kullanan kalın istemci, dağıtılmış yazılım sistemlerinde 5 yıldan fazla çalıştım. Masaüstü, dizüstü bilgisayar (akıllı istemci), mobil cihazlar ve web uygulamaları için uygulamalar geliştirdim, hepsi temel bir fonksiyonel seti paylaşıyor ve aynı sunucu arka ucuyla birçok kez çalışıyor. Bu sırada modülerleştirmenin değerini öğrendim ve çok hızlı bir şekilde kompozit uygulama tasarımı yolunda ilerledim.
Temel fikir, uygulamanızın çalışma zamanı deneyimini "oluşturmak" ve birbirlerini mutlaka bilmeyen birçok küçük parçadan birini işlemektir. Kendilerini genel kompozit uygulama sistemine kaydederler ve daha sonra birbirinden ayrılan mesajlar ve çağrılar yoluyla iletişim kurarlar.
Blogumda bunun hakkında biraz yazdım ve Marionette'i Backbone için kompozit bir uygulama mimarisi olarak tanıttım:
Mesaj Kuyrukları / Desenleri
Aynı büyük ölçekli, dağıtılmış sistemler aynı zamanda ileti sıralaması, kurumsal entegrasyon kalıpları (mesajlaşma kalıpları) ve mesajları işlemek için servis veri yollarından yararlandı. Bu, her şeyden çok, ayrıştırılmış yazılım geliştirme yaklaşımım üzerinde çok büyük bir etkiye sahipti. Tek işlemli, bellek içi WinForms uygulamalarını bu perspektiften görmeye başladım ve yakında sunucu tarafım ve web uygulaması geliştirmem bundan etkilendi.
Bu, kendisini doğrudan Omurga uygulama tasarımına nasıl baktığımıza çevirdi. Hem üst düzey Uygulama nesnesi hem de uygulama içinde oluşturduğunuz her modül için Marionette'de bir olay toplayıcı sağlarım.
Modüllerim arasında gönderebileceğim mesajları düşünüyorum: komut mesajları, olay mesajları ve daha fazlası. Sunucu tarafı iletişimini de aynı kalıplara sahip mesajlar olarak düşünüyorum. Desenlerden bazıları zaten Marionette'e girdi, ancak bazıları henüz olmadı.
modularization
Kodun modülerleştirilmesi son derece önemlidir. İyi tanımlanmış giriş ve çıkış noktalarına sahip tek bir odağa sahip küçük, iyi kapsüllenmiş paketler oluşturmak, önemli boyut ve karmaşıklığa sahip herhangi bir sistem için bir zorunluluktur.
Kukla doğrudan moduletanımları yoluyla modülerleştirme sağlar . Ancak, bazı insanların RequireJS'i sevdiğini ve bunu kullanmak istediğini de biliyorum. Bu yüzden hem standart bir yapı hem de RequireJS uyumlu bir yapı sağlarım.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(Bunun için henüz blog yayını yok)
Artımlı Kullanım
Bu, Marionette'in her parçasına pişirdiğim temel felsefelerden biri: Marionette kullanımı için "ya hep ya hiç" gerekliliği yok.
Omurga, tüm yapı taşı nesneleriyle çok artımlı ve modüler bir yaklaşım benimser. Hangisini ne zaman kullanmak istediğinizi seçmekte özgürsünüz. Bu ilkeye çok inanıyorum ve Marionette'in de aynı şekilde çalıştığından emin olmak için çabalıyorum.
Bu amaçla, Marionette'e inşa ettiğim parçaların çoğu tek başına duracak, Omurga'nın çekirdek parçalarıyla çalışacak ve daha da iyi çalışacak şekilde üretildi.
Örneğin, hemen hemen her Omurga uygulamasının, ekranda belirli bir yerde bir Omurga görünümünü dinamik olarak göstermesi gerekir. Uygulamaların, yeni görünümler yerleştirildiğinde eski görünümlerin kapatılması ve hafızanın temizlenmesi de gerekiyor. Marionette's de burada devreye Regiongiriyor. Bir bölge, bir görünüm almak, üzerinde render oluşturmak ve sonucu sizin için DOM'a doldurmak için ortak plaka kodunu işler. Ardından, görünümünüzde "kapat" yöntemi olması şartıyla bu görünümü kapatır ve sizin için temizler.
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
Ancak bir bölgeyi kullanmak için Marionette'in görüşlerini kullanmanız gerekmez. Tek gereksinim, nesnenin prototip zincirinin bir noktasında Backbone.View'den genişlemenizdir. Bir closeyöntem, onShowyöntem veya başkalarını sağlamayı seçerseniz , Marionette Bölgesi bunu sizin için doğru zamanda arayacaktır.
Sunucu Kilidi Yok
Çok çeşitli sunucu teknolojilerinin üzerine Backbone / Marionette uygulamaları geliştiriyorum:
- ASP.NET MVC
- raylar üzerinde yakut
- Yakut / Sinatra
- NodeJS / ExpressJS
- PHP / İnce
- Java
- Erlang
- ... ve dahası
Tarayıcıda çalışırken JavaScript JavaScript'tir. Sunucu tarafı JavaScript de harika, ancak tarayıcı tabanlı JavaScript'imi nasıl yazdığım üzerinde sıfır etkisi veya etkisi var.
Yaptığım projelerdeki çeşitlilik ve müşterilerimin kullandığı arka uç teknolojileri nedeniyle, Marionette'i herhangi bir nedenle tek bir sunucu tarafı teknoloji yığınına kilitleyemem ve etmeyeceğim. Ortak bir proje vermeyeceğim. Bir yakut mücevher veya npm paketi sağlamayacağım. İnsanların Marionette'in belirli bir arka uç sunucusu gerektirmediğini anlamasını istiyorum. Tarayıcı tabanlı JavaScript ve arka uç önemli değil.
Tabii ki, kendi dilleri ve çerçeveleri için paketler sağlayan diğer insanlara da tam destek veriyorum. Bu paketleri Wiki'de listeliyorum ve insanların ihtiyaç gördükçe daha fazla paket oluşturmaya devam etmelerini umuyorum. Ama bu toplum desteği, Marionette'den doğrudan destek değil.
Varsayılanları Kolayca Değiştirin
Kaynatma plakası kodunu azaltma ve mantıklı varsayılanlar sağlama çabalarımda (bu, Tim Branyen'in LayoutManager'ından doğrudan "ödünç aldığım bir fikirdir), diğer geliştiricilerin benden biraz farklı uygulamalar kullanması gerektiğinin farkındayım.
<script>Varsayılan olarak Underscore.js şablonunu kullanarak şablonlar için satır içi etiketlere dayalı oluşturma sağlarım. Ancak bunu Marionette'deki Rendererve / veya TempalteCachenesneleri değiştirerek değiştirebilirsiniz . Bu iki nesne, oluşturma yeteneklerinin temelini oluşturur ve belirli şablonlama motorları ve şablonların yüklenmesinin farklı yolları için bunun nasıl değiştirileceğini gösteren wiki sayfaları vardır.
Marionette v0.9 ile daha da kolaylaşıyor. Örneğin, satır içi şablon komut dosyası bloklarının kullanımını önceden derlenmiş şablonlarla değiştirmek istiyorsanız, Oluşturucu'da yalnızca bir yöntemi değiştirmeniz gerekir:
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
ve şimdi tüm uygulama, görünümünüzün templateözelliğine eklediğiniz önceden derlenmiş şablonları kullanacaktır .
Hatta senkronize olmayan görünümleri desteklemenizi sağlayan v0.9 içeren bir Marionette.Async eklentisi bile sağlıyorum. Marionette'deki varsayılan davranışları değiştirmeyi mümkün olduğunca kolaylaştırmak için sürekli çaba sarf ediyorum.
Yapılandırma Olarak Kodla
Ben belirli bağlamlarda "yapılandırma konvansiyonu" hayranıyım. Bu, işleri halletmenin güçlü bir yoludur ve Marionette bunun bir kısmını sağlar - çok fazla olmasa da, dürüstçe. Diğer birçok çerçeve - özellikle LayoutManager - yapılandırma üzerinde Marionette'den daha fazla kongre sağlar.
Bu amaç ve niyetle yapılır.
Anlamlı ve hızlı bir şekilde çalışmak için sözleşmeler almaya çalışmanın acısını bilmek için yeterli JavaScript eklentileri, çerçeveler, eklentiler ve uygulamalar geliştirdim. Hızla yapılabilir, ancak genellikle onu değiştirebilme pahasına.
Bu amaçla, Marionette'e bir "konfigürasyon olarak kod" yaklaşımı uyguluyorum. Davranışların bir yığınını değiştiren statik değerlerle bir nesne değişmezi sağlayabileceğiniz bir çok "yapılandırma" API'si sağlamıyorum. Bunun yerine, her nesnenin sahip olduğu yöntemleri - hem açıklamalı kaynak kodu yoluyla hem de gerçek API belgeleri aracılığıyla - Marionette'i istediğiniz gibi çalıştıracak şekilde nasıl değiştireceğinizi anlatmak amacıyla belgeliyorum.
Marionette nesneleri için temiz ve net bir API sağlayarak, belirli bir nesnenin veya Marionette'nin davranışının bir bütün olarak değiştirilmesinin nispeten basit ve çok esnek olduğu bir durum yaratırım. Ben "basit" yapılandırma API çağrıları şeyler istediğiniz şekilde çalışması için kendi kodunu sağlama esnekliği için feda.
Marionette'de "configure" veya "options" API'sini bulamazsınız. Ancak, her birinin çok özel bir amaca hizmet eden, temiz imzalarla Marionette'in çalışma şeklini değiştirmeyi kolaylaştıran çok sayıda yöntem bulacaksınız.
