AngularJS lideri Igor Minar'ın bu gönderisinin bağlamında :

MVC, MVVM ve MVP . Birçok geliştiricinin tartışmak ve tartışmak için saatler harcayabileceği tartışmalı bir konu.

Birkaç yıl angularjs için daha yakın MVC (ya da daha doğrusu onun istemci tarafı biri varyantları), ama zaman ve birçok refactorings ve API iyileştirmeler sayesinde bitmişti, o artık daha yakın MVVM - $ kapsamı nesne düşünülebilir ViewModel ediliyor Denetleyici dediğimiz bir işlevle dekore edilmiştir .

Bir çerçeveyi kategorilere ayırıp onu MV * kovalarından birine yerleştirmenin bazı avantajları vardır. Çerçeve ile inşa edilen uygulamayı temsil eden bir zihinsel model oluşturmayı kolaylaştırarak geliştiricilerin apis'leriyle daha rahat olmalarına yardımcı olabilir. Geliştiriciler tarafından kullanılan terminolojinin oluşturulmasına da yardımcı olabilir.

Bununla birlikte, geliştiricilerin MV * saçmalığı hakkında tartışarak zaman kaybetmelerini görmektense, iyi tasarlanmış ve endişelerin ayrılığını takip eden mükemmel uygulamalar geliştirdiklerini görmeyi tercih ederim. Ve bu nedenle, ben bu vesile ile beyan angularjs olmak Model-View-neyse - MVW çerçeve . " Sizin için işe yarayan" ne anlama gelirse gelsin .

Angular, sunum mantığını iş mantığı ve sunum durumundan güzel bir şekilde ayırmanız için size çok fazla esneklik sağlar. Günün sonunda o kadar da önemli olmayan şeyler hakkında hararetli tartışmalar yerine lütfen onu üretkenliğinizi ve uygulama sürdürülebilirliğinizi besleyin.

İstemci tarafı uygulamalarda AngularJS MVW (Model-View-Whatever) tasarım modelini uygulamaya yönelik herhangi bir öneri veya kılavuz var mı?

Çok sayıda değerli kaynak sayesinde, AngularJS uygulamalarında bileşenlerin uygulanması için bazı genel önerilerim var:

Kontrolör

• Denetleyici, model ve görünüm arasında yalnızca bir ara katman olmalıdır . Mümkün olduğunca ince yapmaya çalışın .

• Denetleyicide iş mantığından kaçınılması şiddetle tavsiye edilir. Modele taşınmalıdır.

• Denetleyici, yöntem çağırma (çocuklar ebeveyn ile iletişim kurmak istediğinde mümkündür) veya $ emit , $ yayın ve $ on yöntemlerini kullanarak diğer denetleyicilerle iletişim kurabilir . Yayılan ve yayınlanan mesajlar minimumda tutulmalıdır.

• Denetleyici, sunum veya DOM manipülasyonunu önemsememelidir .

• Yuvalanmış denetleyicilerden kaçınmaya çalışın . Bu durumda, ebeveyn denetleyici model olarak yorumlanır. Modelleri bunun yerine paylaşılan hizmetler olarak enjekte edin.

• Kapsam denetleyicisi için kullanılmalıdır bağlama görüntüsü modeli ve
  kapsülleyici gör Model gibi sunum modeli tasarım modeli.

Dürbün

Kapsamı şablonlarda salt okunur ve denetleyicilerde salt yazılır olarak ele alın . Kapsamın amacı, model olmak değil, modele atıfta bulunmaktır.

Çift yönlü bağlama (ng-modeli) yaparken, doğrudan osiloskop özelliklerine bağlanmadığınızdan emin olun.

Modeli

Angularjs içinde Modeli olan tekil tarafından tanımlanan hizmet .

Model, verileri ayırmak ve görüntülemek için mükemmel bir yol sağlar.

Modeller, tipik olarak tam olarak bir bağımlılığa (bir tür olay yayıcı, ortak durumda $ rootScope ) sahip oldukları ve yüksek düzeyde test edilebilir alan mantığı içerdikleri için birim testi için birincil adaylardır .

• Model, belirli bir birimin uygulaması olarak düşünülmelidir. Tek sorumluluk ilkesine dayanmaktadır. Birim, gerçek dünyada tek bir varlığı temsil edebilen ve onu veri ve durum açısından programlama dünyasında tanımlayabilen kendi kapsamından sorumlu bir örnektir .

• Model, uygulamanızın verilerini sarmalamalı ve bu verilere erişmek ve bunları değiştirmek için bir API sağlamalıdır .

• Model, benzer uygulamalara kolaylıkla taşınabilmesi için taşınabilir olmalıdır .

• Modelinizde birim mantığını izole ederek, bulmayı, güncellemeyi ve bakımını kolaylaştırdınız.

• Model, tüm uygulama için ortak olan daha genel küresel modellerin yöntemlerini kullanabilir.

• Bileşenlerin birleştirilmesini azaltmaya ve birim test edilebilirliğini ve kullanılabilirliğini artırmaya gerçekten bağımlı değilse, bağımlılık enjeksiyonu kullanarak modelinize diğer modellerin bileşiminden kaçınmaya çalışın .

• Modellerde olay dinleyicilerini kullanmaktan kaçının. Test etmeyi zorlaştırır ve genellikle tek sorumluluk ilkesi açısından modelleri öldürür.

Model Uygulaması

Model, veri ve durum açısından bir miktar mantığı içermesi gerektiğinden, üyelerine erişimi mimari olarak kısıtlamalıdır, böylece gevşek bağlantıyı garanti edebiliriz.

Bunu AngularJS uygulamasında yapmanın yolu, fabrika hizmet türünü kullanarak tanımlamaktır . Bu, özel mülkleri ve yöntemleri çok kolay bir şekilde tanımlamamıza ve ayrıca genel olarak erişilebilir olanları, geliştirici için gerçekten okunabilir hale getirecek şekilde tek bir yerde geri döndürmemize olanak tanır.

Bir örnek :

angular.module('search')
.factory( 'searchModel', ['searchResource', function (searchResource) {

  var itemsPerPage = 10,
  currentPage = 1,
  totalPages = 0,
  allLoaded = false,
  searchQuery;

  function init(params) {
    itemsPerPage = params.itemsPerPage || itemsPerPage;
    searchQuery = params.substring || searchQuery;
  }

  function findItems(page, queryParams) {
    searchQuery = queryParams.substring || searchQuery;

    return searchResource.fetch(searchQuery, page, itemsPerPage).then( function (results) {
      totalPages = results.totalPages;
      currentPage = results.currentPage;
      allLoaded = totalPages <= currentPage;

      return results.list
    });
  }

  function findNext() {
    return findItems(currentPage + 1);
  }

  function isAllLoaded() {
    return allLoaded;
  }

  // return public model API  
  return {
    /**
     * @param {Object} params
     */
    init: init,

    /**
     * @param {Number} page
     * @param {Object} queryParams
     * @return {Object} promise
     */
    find: findItems,

    /**
     * @return {Boolean}
     */
    allLoaded: isAllLoaded,

    /**
     * @return {Object} promise
     */
    findNext: findNext
  };
});

Yeni örnekler oluşturma

Bağımlılık enjeksiyonunu bozmaya başladığından ve kütüphane, özellikle üçüncü şahıslar için tuhaf davranacağından, yeni bir yetenekli işlev döndüren bir fabrikaya sahip olmaktan kaçının.

Aynı şeyi başarmanın daha iyi bir yolu, fabrikayı, alıcı ve ayarlayıcı yöntemleri eklenmiş bir nesne koleksiyonunu döndürmek için bir API olarak kullanmaktır.

angular.module('car')
 .factory( 'carModel', ['carResource', function (carResource) {

  function Car(data) {
    angular.extend(this, data);
  }

  Car.prototype = {
    save: function () {
      // TODO: strip irrelevant fields
      var carData = //...
      return carResource.save(carData);
    }
  };

  function getCarById ( id ) {
    return carResource.getById(id).then(function (data) {
      return new Car(data);
    });
  }

  // the public API
  return {
    // ...
    findById: getCarById
    // ...
  };
});

Global Model

Genel olarak bu tür durumlardan kaçınmaya çalışın ve modellerinizi doğru şekilde tasarlayın, böylece kontrolöre enjekte edilebilir ve sizin görüşünüzde kullanılabilir.

Özel durumda, bazı yöntemler uygulama içinde küresel erişilebilirliği gerektirir. Bunu mümkün kılmak için $ rootScope içinde ' common ' özelliği tanımlayabilir ve uygulama önyüklemesi sırasında bunu commonModel'e bağlayabilirsiniz :

angular.module('app', ['app.common'])
.config(...)
.run(['$rootScope', 'commonModel', function ($rootScope, commonModel) {
  $rootScope.common = 'commonModel';
}]);

Tüm küresel yöntemleriniz ' ortak ' mülk içinde yaşayacaktır . Bu bir tür ad alanıdır .

Ancak doğrudan $ rootScope'unuzda herhangi bir yöntem tanımlamayın . Bu, görüş kapsamınız dahilinde ngModel yönergesi ile birlikte kullanıldığında beklenmedik davranışlara yol açabilir , genellikle kapsamınızı bozar ve kapsam yöntemlerinin sorunları geçersiz kılmasına yol açar.

Kaynak

Kaynak, farklı veri kaynaklarıyla etkileşim kurmanıza olanak tanır .

Tek sorumluluk ilkesi kullanılarak uygulanmalıdır .

Özel durumda , HTTP / JSON uç noktaları için yeniden kullanılabilir bir proxy'dir.

Kaynaklar modellere enjekte edilir ve veri gönderme / alma imkanı sağlar.

Kaynak uygulaması

RESTful sunucu tarafı veri kaynaklarıyla etkileşim kurmanıza izin veren bir kaynak nesnesi oluşturan bir fabrika.

Döndürülen kaynak nesnesi, düşük seviyeli $ http hizmetiyle etkileşime girmeye gerek kalmadan yüksek düzeyde davranışlar sağlayan eylem yöntemlerine sahiptir.

Hizmetler

Hem model hem de kaynak hizmetlerdir .

Hizmetler, birbiriyle ilişkili olmayan, gevşek bir şekilde bağlı işlevsellik birimleridir.

Hizmetler, Angular'ın, hizmetlerin uzun süredir yaygın olarak kullanıldığı sunucu tarafından istemci tarafı web uygulamalarına getirdiği bir özelliktir.

Angular uygulamalarındaki hizmetler, bağımlılık ekleme kullanılarak birbirine bağlanan değiştirilebilir nesnelerdir.

Angular, farklı hizmet türleriyle birlikte gelir. Her birinin kendi kullanım durumları vardır. Ayrıntılar için lütfen Hizmet Türlerini Anlama bölümünü okuyun .

Uygulamanızda servis mimarisinin ana prensiplerini göz önünde bulundurmaya çalışın .

Genel olarak Web Hizmetleri Sözlüğü'ne göre :

Bir hizmet, sağlayıcıların ve talep edenlerin bakış açısından uyumlu bir işlevsellik oluşturan görevleri gerçekleştirme yeteneğini temsil eden soyut bir kaynaktır. Kullanılabilmesi için, bir hizmet somut bir sağlayıcı acentesi tarafından gerçekleştirilmelidir.

İstemci tarafı yapısı

Genelde uygulamanın istemci tarafı modüllere ayrılmıştır . Her modül bir birim olarak test edilebilir olmalıdır .

Modülleri türe göre değil , özellik / işlev veya görünüme göre tanımlamaya çalışın . Ayrıntılar için Misko'nun sunumuna bakın.

Modül bileşenleri, geleneksel olarak denetleyiciler, modeller, görünümler, filtreler, yönergeler vb. Türlere göre gruplandırılabilir.

Ancak modülün kendisi yeniden kullanılabilir , aktarılabilir ve test edilebilir olmaya devam ediyor .

Ayrıca geliştiricilerin kodun bazı bölümlerini ve tüm bağımlılıklarını bulması çok daha kolaydır.

Ayrıntılar için lütfen Büyük AngularJS ve JavaScript Uygulamalarında Kod Organizasyonuna bakın .

Klasör yapılandırmasına bir örnek :

|-- src/
|   |-- app/
|   |   |-- app.js
|   |   |-- home/
|   |   |   |-- home.js
|   |   |   |-- homeCtrl.js
|   |   |   |-- home.spec.js
|   |   |   |-- home.tpl.html
|   |   |   |-- home.less
|   |   |-- user/
|   |   |   |-- user.js
|   |   |   |-- userCtrl.js
|   |   |   |-- userModel.js
|   |   |   |-- userResource.js
|   |   |   |-- user.spec.js
|   |   |   |-- user.tpl.html
|   |   |   |-- user.less
|   |   |   |-- create/
|   |   |   |   |-- create.js
|   |   |   |   |-- createCtrl.js
|   |   |   |   |-- create.tpl.html
|   |-- common/
|   |   |-- authentication/
|   |   |   |-- authentication.js
|   |   |   |-- authenticationModel.js
|   |   |   |-- authenticationService.js
|   |-- assets/
|   |   |-- images/
|   |   |   |-- logo.png
|   |   |   |-- user/
|   |   |   |   |-- user-icon.png
|   |   |   |   |-- user-default-avatar.png
|   |-- index.html

Açısal uygulama yapılanma dair iyi bir örnek tarafından uygulanan açısal uygulama içi - https://github.com/angular-app/angular-app/tree/master/client/src

Bu aynı zamanda modern uygulama oluşturucuları tarafından da dikkate alınır - https://github.com/yeoman/generator-angular/issues/109

Sağladığınız alıntıda görüldüğü gibi, Igor'un bunu üstlenmesinin çok daha büyük bir sorunun buzdağının görünen kısmı olduğuna inanıyorum.

MVC ve türevleri (MVP, PM, MVVM) tek bir ajan içinde iyi ve zekidir, ancak bir sunucu-istemci mimarisi tüm amaçlar için iki ajanlı bir sistemdir ve insanlar genellikle bu modellere o kadar takıntılıdır ki, bunu unuturlar. eldeki sorun çok daha karmaşık. Bu ilkelere bağlı kalmaya çalışarak, aslında kusurlu bir mimari ile sonuçlanırlar.

Bunu yavaş yavaş yapalım.

Yardımcı notlar

Görüntüleme

Açısal bağlam içinde, görünüm DOM'dir. Yönergeler şunlardır:

Yapmak:

• Kapsam değişkenini sun (salt okunur).
• Eylemler için denetleyiciyi arayın.

Yapmayın:

• Herhangi bir mantık koyun.

Cazip, kısa ve zararsız bu görünüyor:

ng-click="collapsed = !collapsed"

Sistemin nasıl çalıştığını anlamak için hem Javascript dosyalarını hem de HTML dosyalarını incelemeye ihtiyaç duyan geliştiricilere hemen hemen işaret ediyor.

Kontrolörler

Yapmak:

• Kapsama veri yerleştirerek görünümü 'modele' bağlayın.
• Kullanıcı eylemlerine yanıt verin.
• Sunum mantığıyla ilgilenin.

Yapmayın:

• Herhangi bir iş mantığıyla başa çıkın.

Son kılavuzun nedeni, denetleyicilerin varlıkların değil, görüşlerin kardeşleridir; ne de yeniden kullanılabilirler.

Yönergelerin yeniden kullanılabilir olduğunu iddia edebilirsiniz, ancak yönergeler de görüşlere kardeştir (DOM) - asla varlıklara karşılık gelmeleri amaçlanmamıştır.

Elbette bazen görüşler varlıkları temsil eder, ancak bu oldukça özel bir durumdur.

Başka bir deyişle, kontrolörler sunuma odaklanmalıdır - eğer iş mantığını devreye sokarsanız, sadece şişirilmiş, az yönetilebilir bir kontrolörle sonuçlanmayacak , aynı zamanda endişe ayrımı ilkesini de ihlal etmiş olacaksınız .

Bu nedenle, Angular'daki kontrolörler gerçekten daha çok Sunum Modeli veya MVVM'dir .

Öyleyse, kontrolörler iş mantığıyla ilgilenmiyorsa, kim yapmalı?

Model nedir?

Müşteri modeliniz genellikle kısmi ve eski

Çevrimdışı bir web uygulaması veya son derece basit (birkaç varlık) bir uygulama yazmıyorsanız, müşteri modeliniz büyük olasılıkla:

• Kısmi
  • Ya tüm varlıklara sahip değil (sayfalandırma durumunda olduğu gibi)
  • Veya tüm verilere sahip değil (sayfalandırma durumunda olduğu gibi)
• Eski - Sistemin birden fazla kullanıcısı varsa, herhangi bir noktada istemcinin sahip olduğu modelin sunucunun sahip olduğu modelle aynı olduğundan emin olamazsınız.

Gerçek model devam etmeli

Geleneksel MCV'de, model kalıcı olan tek şeydir . Modeller hakkında ne zaman konuşsak, bunlar bir noktada ısrar etmelidir. İstemciniz modelleri istediği zaman değiştirebilir, ancak sunucuya gidiş dönüş başarılı bir şekilde tamamlanana kadar iş tamamlanmaz.

Sonuçlar

Yukarıdaki iki nokta bir uyarı görevi görmelidir - müşterinizin sahip olduğu model yalnızca kısmi, çoğunlukla basit bir iş mantığını içerebilir.

Bu nedenle, müşteri bağlamında küçük harf kullanmak belki akıllıca olacaktır M- bu yüzden gerçekten mVC , mVP ve mVVm'dir . Büyük Molan sunucu içindir.

İş mantığı

İş modelleriyle ilgili belki de en önemli kavramlardan biri, bunları 2 türe ayırabilmenizdir (üçüncü bakış açısını , başka bir günün hikayesi olduğu için atlıyorum):

• Etki alanı mantığı - diğer adıyla Kurumsal iş kuralları , uygulamadan bağımsız mantık. Örneğin, firstNameve sirNameözelliklerine sahip bir model verin , bir alıcı benzeri getFullName()uygulamadan bağımsız kabul edilebilir.
• Uygulama mantığı - diğer bir deyişle , uygulamaya özel olan Uygulama iş kuralları . Örneğin, hata kontrolleri ve işleme.

Bir müşteri bağlamında her ikisinin de 'gerçek' iş mantığı olmadığını vurgulamak önemlidir - sadece müşteri için önemli olan kısmıyla ilgilenirler. Uygulama mantığı (etki alanı mantığı değil), sunucuyla iletişimi ve çoğu kullanıcı etkileşimini kolaylaştırma sorumluluğuna sahip olmalıdır; etki alanı mantığı büyük ölçüde küçük ölçekli, varlığa özgü ve sunum odaklı.

Soru hala kalır - bunları açısal bir uygulamanın içinde nereye atarsınız?

3'e karşı 4 katmanlı mimari

Tüm bu MVW çerçeveleri 3 katman kullanır:

Ancak müşteriler söz konusu olduğunda bununla ilgili iki temel sorun var:

• Model kısmi, eski ve kalıcı değil.
• Uygulama mantığını koyacak yer yok.

Bu stratejinin bir alternatifi 4 katmanlı stratejidir :

Buradaki gerçek anlaşma, genellikle istemcilerde ters giden uygulama iş kuralları katmanıdır (Kullanım senaryoları).

Bu katman, Martin Fowler'ın bir işlem komut dosyası hizmet katmanı dediği şey olan, interaktörler (Bob Amca) tarafından gerçekleştirilir .

Somut örnek

Aşağıdaki web uygulamasını düşünün:

• Uygulama sayfalara ayrılmış bir kullanıcı listesi gösterir.
• Kullanıcı "Kullanıcı ekle" yi tıklar.
• Kullanıcı ayrıntılarını doldurmak için bir form içeren bir model açılır.
• Kullanıcı formu doldurur ve gönder düğmesine basar.

Şimdi birkaç şey gerçekleşmeli:

• Form, müşteri tarafından doğrulanmalıdır.
• Sunucuya bir istek gönderilecektir.
• Varsa bir hata ele alınacaktır.
• Kullanıcı listesinin güncellenmesi gerekebilir veya olmayabilir (sayfalandırma nedeniyle).

Tüm bunları nereye atacağız?

Mimariniz çağıran bir denetleyici içeriyorsa $resource, tüm bunlar denetleyicide gerçekleşir. Ancak daha iyi bir strateji var.

Önerilen bir çözüm

Aşağıdaki şema, Angular istemcilere başka bir uygulama mantığı katmanı ekleyerek yukarıdaki sorunun nasıl çözülebileceğini gösterir:

Bu yüzden, controller ile $ resource arasına bir katman ekliyoruz, bu katman (buna interactor diyelim ):

• Bir hizmettir . Kullanıcılar söz konusu olduğunda çağrılabilir UserInteractor.
• Bu yöntemler, tekabül eden sağlayan durumlarda kullanmak , uygulama mantığı kapsül .
• Bu kontrol sunucuya yapılan istekleri. Serbest biçimli parametrelerle $ kaynağı çağıran bir denetleyici yerine, bu katman, sunucuya yapılan isteklerin etki alanı mantığının üzerinde çalışabileceği verileri döndürmesini sağlar.
• Döndürülen veri yapısını etki alanı mantığı prototipi ile dekore eder .

Ve böylece, yukarıdaki somut örneğin gereklilikleriyle:

• Kullanıcı "Kullanıcı ekle" yi tıklar.
• Denetleyici, uygulayıcıdan boş bir kullanıcı modeli ister, iş mantığı yöntemi ile dekore edilmiştir. validate()
• Gönderildikten sonra, kontrolör model validate()yöntemini çağırır .
• Başarısız olursa, denetleyici hatayı ele alır.
• Başarılı olursa, kontrolör uygulayıcıyı createUser()
• Uygulayıcı $ resource'u çağırır
• Yanıt üzerine, uygulayıcı hataları işleyen denetleyiciye devreder.
• Başarılı yanıtın ardından uygulayıcı, gerekirse kullanıcı listesinin güncellenmesini sağlar.

Artem'in cevabındaki büyük tavsiyelere kıyasla küçük bir sorun, ancak kod okunabilirliği açısından, returndeğişkenlerin tanımlandığı her yere bakmak için kodda ileri geri gitmeyi en aza indirmek için API'yi tamamen nesnenin içinde tanımlamayı en iyi buldum :

angular.module('myModule', [])
// or .constant instead of .value
.value('myConfig', {
  var1: value1,
  var2: value2
  ...
})
.factory('myFactory', function(myConfig) {
  ...preliminary work with myConfig...
  return {
    // comments
    myAPIproperty1: ...,
    ...
    myAPImethod1: function(arg1, ...) {
    ...
    }
  }
});

Eğer returnnesne görünümlü hale Servis çok fazla yaptığını belirtisi olduğunu, "çok kalabalık".

AngularJS, MVC'yi geleneksel şekilde uygulamaz, bunun yerine MVVM'ye (Model-View-ViewModel) daha yakın bir şey uygular, ViewModel ayrıca bağlayıcı olarak da adlandırılabilir (açısal durumda, $ kapsam olabilir). Model -> Bildiğimiz gibi açısal model sadece düz eski JS nesneleri veya uygulamamızdaki veriler olabilir.

Açısal JS'deki Görünüm -> görünüm, direktifler veya talimatlar veya bağlamalar uygulanarak angularJS tarafından ayrıştırılan ve derlenen HTML'dir. Buradaki ana nokta, açısal olarak girişin yalnızca düz HTML dizesi (internalHTML) değil, DOM, tarayıcı tarafından oluşturulmuştur.

ViewModel -> ViewModel, aslında, Controller'ı kullandığımız $ kapsamını başlatmak ve genişletmek için, angularJS durumunda görünümünüz ve modeliniz arasındaki bağlayıcı / köprüdür.

Cevabı özetlemek istersem: angularJS uygulamasında $ kapsam, verilere referans verir, Controller davranışı kontrol eder ve View, uygun şekilde davranmak için kontrolörle etkileşim kurarak düzeni işler.

Angular, soru hakkında net olmak için, normal programlamamızda zaten karşılaştığımız farklı tasarım modellerini kullanır. 1) Modülümüzle ilgili olarak kontrolörlerimizi veya direktiflerimizi, fabrikamızı, hizmetlerimizi vb. Kaydettiğimizde. Burada verileri global uzaydan saklıyor. Hangisi Modül desen . 2) Açısal, kapsam değişkenlerini karşılaştırmak için kirli kontrolünü kullandığında, burada Gözlemci Modeli kullanır . 3) Denetleyicilerimizdeki tüm üst alt kapsamlar Prototypal kalıbı kullanır . 4) Servislerin enjekte edilmesi durumunda Factory Pattern kullanır .

Genel olarak, sorunları çözmek için bilinen farklı tasarım modellerini kullanır.