Robię dość złożoną aplikację emberjs i wiążę ją z zapleczem API.

Wywołania API zazwyczaj nie są powiązane z żadnym konkretnym modelem, ale mogą zwracać obiekty różnych typów w różnych sekcjach odpowiedzi, np. wywołanie API zdarzeń zwróci zdarzenia, ale również zwróci zasoby multimedialne i osoby zaangażowane w te zdarzenia.

Właśnie zacząłem od projektu i chciałbym uzyskać pewne wskazówki ekspertów, jak najlepiej rozdzielić obawy, aby mieć czystą bazę kodu do utrzymania.

Oto sposób, w jaki się zbliżam:

Modele: zasadniczo obsługuj rekordy z ich polami i innymi obliczonymi właściwościami. Jednak modele nie są odpowiedzialne za składanie wniosków.na przykład Indywidualny, Event, Picture, Post itp.Sklepy: Są to zasadniczo pamięci podręczne. Na przykład aneventStore przechowuje do tej pory wszystkie zdarzenia odebrane z serwera (z możliwie różnych żądań) w tablicy, a także w mieszance zdarzeń indeksowanych przezid.na przykład individualStore, eventStore itp.Kontrolery: Wiążą się z zestawem powiązanych wywołań API, np. eventsController byłby odpowiedzialny za pobieranie zdarzeń lub określonego zdarzenia, lub tworzenie nowego zdarzenia itp. „Kierował” odpowiedź na różnestores do późniejszego pobrania. Nie zachowują odpowiedzi po wysłaniu do sklepów.na przykład eventsController, userSearchController itp.Widoki: Są związane z konkretnym widokiem. Ogólnie moja aplikacja może mieć kilka widoków w różnych miejscach, np.latestEventsView na pulpicie nawigacyjnym oprócz oddzielnej strony wydarzeń.Szablony: są tym, czym są.

Często moje szablony wymagają bezpośredniego powiązania ze sklepami (np.peopleView chce wyświetlić listę wszystkich osób w IndividualStore na liście, posortowanych według jakiegoś zamówienia).

Czasami wiążą się z obliczoną własnością

<code>alivePeople: function () { ... }.property('App.individualStore.content.@each'),
</code>

Różne „wybrane” opcje filtrowania i sortowania w widoku powinny zwracać różne listy ze sklepu. Możesz zobaczyć moje ostatnie pytanie najaki jest właściwy sposób emberjsa na przełączanie się między różnymi opcjami filtrowania?

Kto powinien robić to filtrowanie, sam widok lub sklepy?

Czy ten rodzaj powiązania między warstwami jest dobry, czy zapach kodu? Czy rozdzielenie spraw jest dobre, czy coś mi brakuje? Czy kontrolerzy nie powinni robić tutaj więcej? Czy moje widoki powinny być bezpośrednio powiązane ze sklepami?

Każdy szczególny przypadek MVC bardziej dopasowany do moich potrzeb?

Aktualizacja 17 kwietnia 2012 r Moje badania trwają, szczególnie zhttp://vimeo.com/user7276077/videos ihttp://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html ihttp://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Niektóre problemy z moim projektem, które odkryłem, to:

kontrolery wysyłające żądania (sklepy lub modele lub coś innego powinno to robić, nie kontrolery)brak statystyk - są one ważne dla interakcji widok-kontroler (po pewnym czasie zdajesz sobie sprawę, że twoje interakcje nie są prostsze)

To dobry przykład wykresów stanu w działaniu:https://github.com/DominikGuzei/ember-routing-statechart-example

AKTUALIZACJA 9 STYCZNIA 2013

Tak, minęło dużo czasu, ale ostatnio pojawia się wiele pytań i dlatego chciałbym je edytować, aby ludzie mogli mieć sens.

Krajobraz Embera bardzo się zmienił, odkąd to pytanie zostało sformułowane i noweprzewodniki są znacznie ulepszone. EmberJS opracował konwencje (takie jak Rails), a MVC jest teraz znacznie lepiej zdefiniowany.

Każdy, kto nadal jest zdezorientowany, powinien przeczytać wszystkie przewodniki i obejrzeć kilka filmów:Seattle Ember.js Meetup

W tej chwili aktualizuję swoją aplikację doEmber.js 1.0.0-pre2.