2016-03-08 20 views
8

Görünüm denetimlerimi yapılandırmak ve verilerini temsil etmek için Model Görünümü ViewModel paradigmasını kullanarak iOS uygulamaları geliştiriyorum. ReactiveCocoa ile birlikte güçlü bir araçtır; denetleyicilerin daha az şişirilmiş olmasını sağlayın, görünüm modellerini test etmek daha kolaydır ve açık bir endişe ayrılığı vardır.MVVM genel ağ mimarisi

Bu mimaride sahip olduğum tek sorun, MVC gibi, hala ağ kodunun yapılandırılması için net bir yer veya yol olmadığını gösteriyor. Aşağıdaki önemsiz örneği ele alalım : görünüm kumandam içinde Sonra

class HomepageViewModel { 
    var posts: MutableProperty<[Post]> = MutableProperty([]) 

    func fetchPosts() -> SignalProducer<[Post], NSError> { 
     return SignalProducer { observer, disposable in 
      // do some networking stuff 
      let posts = .... 
      observer.sendNext(posts) 
      observer.sendCompleted() 
     } 
    } 
} 

yere Yapabileceğim: Bana göre

self.viewModel.posts <~ self.viewModel.fetchPosts().on(next: { _ in self.collectionView.reloadData() }) 

o MVVM görüş ve görünümü maruz oldu kullanmanın bütün mesele gibi hissediyor Herhangi bir ağ koduna herhangi bir denetleyici (ne ben sunum sunusu katmanı diyoruz) ama yine de, yeni içeriğin özelliklerin bilmeden alındığını gözlemlemek için bir yola ihtiyacım var, sadece başarılı bir getirme gerçekleşti. Ben de benim <~ kullanımıyla ilgili değişken özelliklerine sinyalleri ve sinyal üreticileri bağlama yeteneğini kaybetmek istemiyoruz, aynı zamanda

self.viewModel.contentUpdatedSignal.observeNext { _ in self.collectionView.reloadData() } 

: Ben böyle bir şey olmazdı hayal ediyorum.

class ViewModel { 
    let someProperty = MutableProperty<[SomeModel]>([]) 
    var (contentUpdatedSignal, observer) = Signal.pipe() 
    init() { 
     self.someProperty <~ self.fetchContent().on(next: { _ in observer.sendNext() } 
    } 

    func fetchContent() -> SignalProducer<[SomeModel], NSError> { 
     // do some fun stuff 
    } 
} 

Bunu yapmanın Bu yöntem biraz daha iyi ama yine de sinyal izleyici üzerinde sonraki olay göndermek için yan etkileri kullanır ve bir ortak ViewModel temel sınıf kullanıyorsanız, bunu o gözlemci maruz kalmaları bu alt sınıflar bunu kullanabilir.

MVVM mimarisine yapılabilecek herhangi bir gelişme olup olmadığını, mimarinin kendisinde değişiklik yapmamayı ve böylece MVVM'nin artık olmamasını ve ağların daha iyi ve daha genel bir şekilde ve hatta bir tür genel temel iletişim kuralıyla yapılmasını sağlıyorum. tüm süreci soyutlayan görünüm modelleri için.

Benim için, mümkün olduğu kadar genel olarak mümkün olduğunca genel model olmak, görünüm modeliyle ilgili mümkün olduğunca az bilgi içeriyor. İdeal olarak, her bir görüntü denetleyicisinin ağ modelinin nasıl çalıştığı konusunda tam olarak aynı modelle etkileşimde bulunmak istiyorum.

DÜZENLEME:

Başına @ lonut önerisi, benim modeli sınıfları ama sadece statik yöntemlere ağ kodu bazı taşındı:

import Foundation 
import ReactiveCocoa 
import Moya 

protocol RESTModel { 
    typealias Model 

    static func create(parameters: [NSObject: AnyObject]?) -> SignalProducer<Model, Moya.Error> 
    static func find() -> SignalProducer<Model, Moya.Error> 
    static func get(id: String) -> SignalProducer<Model, Moya.Error> 
    static func update(id: String) -> SignalProducer<Model, Moya.Error> 
    static func remove(id: String) -> SignalProducer<Model, Moya.Error> 

} 

extension RESTModel { 
    static func create(parameters: [NSObject: AnyObject]? = nil) -> SignalProducer<Self.Model, Moya.Error> { 
     return SignalProducer.empty 
    } 
    static func find() -> SignalProducer<Self.Model, Moya.Error> { 
     return SignalProducer.empty 
    } 
    static func get(id: String) -> SignalProducer<Self.Model, Moya.Error> { 
     return SignalProducer.empty 
    } 
    static func update(id: String) -> SignalProducer<Self.Model, Moya.Error> { 
     return SignalProducer.empty 
    } 
    static func remove(id: String) -> SignalProducer<Self.Model, Moya.Error> { 
     return SignalProducer.empty 
    } 
} 

modelleri ağını uygulamak Bu şekilde iradesiyle çağrıları hangi

bir User modele sahip düşünün vb spesifik Moya ağ aramaları, tepki nesnelerin haritalama gibi uygulama ayrıntılarını uzakta abstracting yararı vardır:

Görünüm denetleyicisinin ve görünüm modelinin birbiriyle nasıl etkileşim kurması gerektiği konusunu tamamen çözmez, ancak ağ kodunu kesinlikle tek bir hata noktasına taşır.

cevap

1

MVVM veya RAC kullanmama konusunda çok ileri gelmedim, ancak ağ kodunda oynadığım modelden model parçasında olması gereken bir şey var, o zaman görünüm modelindeki sonuçları gözlemleyen bir yöntem var. fetchPosts() ") ve görünüm kısmında fetchPosts yöntemi çağrılır.Daha fazla bilgi için this blog post'u tavsiye ederim.

+0

Modelin sadece bir veri temsili olması gerektiğinden, katılmıyorum. Veri getirme yöntemleri, sınıf yöntemleri değil, örnek yöntemler olduğu sürece çalışabilir. – barndog

+0

Posta kodu Post kodu gibi bir ağ modeli olduğunu düşünmekteyim, Post modelinin de ağ kodunu içermesi gerekmiyor. – Ionut