EmberJS: Dobre rozdzielenie obaw dotyczących modeli, sklepów, kontrolerów, widoków w dość złożonej aplikacji?

Question

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

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

Właśnie rozpocząłem pracę nad projektem i chciałbym uzyskać porady ekspertów na temat tego, jak najlepiej rozdzielić zapytania, aby uzyskać czystą i łatwą do utrzymania podstawę kodu.

The Way I Am zbliża to:

• modele: zasadniczo obsługiwać rekordy ze swoich pól i innych właściwości komputerowej. Modele nie są jednak odpowiedzialne za składanie wniosków.
  • np. Indywidualne, wydarzenie, zdjęcie, wpis itp.
• Sklepy: Są to głównie skrytki. Na przykład: eventStore będzie przechowywać wszystkie zdarzenia odebrane z serwera do tej pory (z możliwych różnych żądań) w tablicy, a także w hashu wydarzeń indeksowanych przez id.
  • np. individualStore, eventStore itp.
• Kontrolery: Są powiązane z zestawem powiązanych wywołań API, np. eventsController będzie odpowiedzialny za pobieranie zdarzeń lub określonego zdarzenia, lub tworzenie nowego wydarzenia itp. Będą "trasować" odpowiedź do innej stores w celu późniejszego pobrania. Nie zachowują odpowiedzi po przesłaniu jej do sklepów.
  • np. eventsController, userSearchController itp.
• Widoki: Są powiązane z określonym widokiem. Ogólnie moja aplikacja może mieć kilka widoków w różnych miejscach, np. latestEventsView na pulpicie nawigacyjnym oprócz posiadania osobnej strony wydarzeń.
• Szablony: są tym, czym są.

Często moi szablony wymagają wiązać się bezpośrednio do sklepów (np peopleView chce wymienić wszystkich osób w individualStore na liście posortowane według pewnej kolejności).

I czasami wiążą się właściwości komputerowej

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

różnych filtrowanie i opcje sortowania „wybrane” w widoku, należy wrócić różnych list ze sklepu. Możesz zobaczyć moje ostatnie pytanie pod adresem what is the right emberjs way to switch between various filtering options?

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

Czy ten rodzaj wiązania w poprzek warstw, czy zapach kodu? Czy rozdzielenie spraw jest dobre, czy też czegoś brakuje? Czy kontrolerzy nie powinni robić tutaj czegoś więcej? Czy moje poglądy bezpośrednio wiążą się ze sklepami?

Dowolny szczególny przypadek MVC bardziej odpowiadający moim potrzebom?

Aktualizacja 17 kwietnia 2012 Moje badania trwa, szczególnie z http://vimeo.com/user7276077/videos i http://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html i http://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Niektóre problemy z mojego projektu, że zorientowali się, to:

• kontrolery (making żądań sklepy lub modele lub coś innego powinno to robić, a nie kontrolery)
• Brakuje wykresów statystycznych - są one ważne dla interakcji widok-kontroler (Po jakimś czasie okazuje się swoimi interakcje nie są bardziej proste)

Jest to dobry przykład wykresów państwowych w akcji: https://github.com/DominikGuzei/ember-routing-statechart-example

UPDATE 09 stycznia 2013

Tak, to był długi, ale to pytanie ma ostatnio wiele wyświetleń i dlatego chciałbym je edytować, żeby ludzie mieli poczucie.

Krajobraz Ember bardzo się zmienił od czasu sformułowania tego pytania, a nowe guides zostały znacznie ulepszone. EmberJS wymyślił konwencje (takie jak Rails), a MVC jest teraz znacznie lepiej zdefiniowane.

ktoś nadal mylone powinien przeczytać wszystkie prowadnice i obejrzeć kilka filmów: Seattle Ember.js Meetup

Obecnie jestem modernizacji mój wniosek do Ember.js 1.0.0-pre2.

Answer 1

• Powinieneś pomyśleć o aplikacji pod względem stanów. Wystarczy popatrzeć na this

• Początkowo tylko trasa i szablon są wymagane do opisania coś wreszcie wyświetlić go w przeglądarce, to właśnie nowa API Emberjs próbuje egzekwować. Gdy Twoje wymagania będą bardziej szczegółowe, możesz rzucić widok, kontroler lub obiekt. Każdy odpowiada jednak na konkretne zapotrzebowanie.

• Rozważmy pogląd, jeśli chcesz obsługiwać żadnych zdarzeń przeglądarki lub owinąć
  każdy 3rd party javascript lib używasz do animacji, stylizacji ..

• Rozważmy obiektu, jeśli trzeba zarejestrować domenę specyficzną
  informacje, najprawdopodobniej naśladują informacje backendu.

• Kontroler jest po prostu pełnomocnikiem dla obiektu domeny i może zawierać logikę, która niekoniecznie odnosi się do obiektu.

To wszystko, co jest do tego. Jeśli dowiesz się, jak zaprojektować aplikację pod kątem stanów, reszta znajdzie się we właściwym miejscu, pod warunkiem, że używasz najnowszego API, wymuszając zasady, o których wspomniałem wcześniej.

Answer 2

Zobacz także ten http://addyosmani.com/largescalejavascript/ Nie chodzi w szczególności o EmberJs, ale jest to świetny artykuł, który daje ci pomysł, jak pisać aplikacje javascript na dużą skalę.

Answer 3

Od wydania Ember 1.0.0-pre4 z nową implementacją routera widziałem dwa dobre odniesienia opisujące znormalizowaną strukturę aplikacji EmberJS.

Ci z was, którzy znają Railsa, uznają go za całkiem znajomy.

https://github.com/trek/ember-todos-with-build-tools-tests-and-other-modern-conveniences

http://reefpoints.dockyard.com/ember/2013/01/07/building-an-ember-app-with-rails-api-part-1.html

Projekt ember barierki w https://github.com/emberjs/ember-rails zawiera generator szyny do tworzenia struktury katalogów zastosowanie EmberJS, która jest zasadniczo taka sama jak konstrukcja opisanych w dwóch połączeń powyższych.

Przewodniki EmberJS również opisują teraz nową strukturę routingu.http://emberjs.com/guides/

UPDATE 21/08/2013

Jeśli używasz Rails to klejnot ember barierki jest wielki. Używałem go z dużym sukcesem. We wspólnocie ember są dwa wysiłki, aby pomóc w zapewnieniu znormalizowanego układu aplikacji ember. Podobno mają zamiar zostać połączone ale teraz sprawdź:

https://github.com/rpflorence/ember-tools

https://github.com/stefanpenner/ember-app-kit