Estou fazendo um aplicativo emberjs bastante complexo e vinculando-o a um backend de APIs.

As chamadas de API geralmente não são vinculadas a nenhum modelo específico, mas podem retornar objetos de vários tipos em seções diferentes da resposta, por exemplo, uma chamada para a API de eventos retornaria eventos, mas também retornaria ativos de mídia e indivíduos envolvidos nesses eventos.

Acabei de começar o projeto e gostaria de obter algumas orientações especializadas sobre a melhor maneira de separar as preocupações para ter uma base de código de manutenção limpa.

A maneira como estou me aproximando disso é:

Modelos: essencialmente manipular registros com seus campos e outras propriedades calculadas. No entanto, os modelos não são responsáveis ​​por fazer solicitações.por exemplo. Individual, Evento, Imagem, Post, etc.Lojas: Eles são essencialmente caches. Por exemplo, umeventStore armazenaria todos os eventos recebidos do servidor até o momento (possivelmente de diferentes solicitações) em uma matriz e também em um hash de eventos indexados porid.por exemplo. individualStore, eventStore etc.Controladores: Vinculam-se a um conjunto de chamadas de API relacionadas, por exemplo, eventsController seria responsável por buscar eventos ou um evento particular, ou criar um novo evento, etc. Eles iriam "direcionar" a resposta para diferentesstores para posterior recuperação. Eles não mantêm a resposta depois que ela é enviada para as lojas.por exemplo. eventsController, userSearchController etc.Views: Eles estão ligados a uma visão particular. Em geral, minha inscrição pode ter várias visualizações em lugares diferentes, por exemplo,latestEventsView no Painel, além de ter uma página de eventos separada.Modelos: são o que são.

Muitas vezes, meus modelos precisam ser vinculados diretamente às lojas (por exemplo,peopleView deseja listar todos os indivíduos na individualStore em uma lista, classificados por algum pedido).

E, às vezes, eles se ligam a uma propriedade computada

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

As várias opções de filtragem e classificação 'escolhidas' na exibição devem retornar listas diferentes da loja. Você pode ver minha última pergunta emQual é a melhor maneira de trocar entre várias opções de filtragem?

Quem deve fazer essa filtragem, a visão em si ou as lojas?

Esse tipo de ligação entre camadas é bom ou um cheiro de código? A separação das preocupações é boa ou estou perdendo alguma coisa? Os controladores não deveriam estar fazendo algo mais aqui? As minhas visualizações devem ligar-se diretamente às lojas?

Qualquer caso especial especial de MVC mais adequado às minhas necessidades?

Atualização 17 de abril de 2012 Minha pesquisa continua, particularmente a partir dehttp://vimeo.com/user7276077/videos ehttp://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html ehttp://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Alguns problemas com o meu design que descobri são:

controladores fazendo pedidos (lojas ou modelos ou qualquer outra coisa deve fazê-lo, não controladores)está faltando statecharts - eles são importantes para as interações do controlador de visualização (depois de algum tempo você percebe que suas interações não são mais simples)

Este é um bom exemplo de gráficos de estado em ação:https://github.com/DominikGuzei/ember-routing-statechart-example

ATUALIZAÇÃO 9 DE JANEIRO DE 2013

Sim, tem sido longo, mas ultimamente esta questão está recebendo muitos pontos de vista, e é por isso que eu gostaria de editá-la para que as pessoas possam ter uma ideia.

O panorama de Ember mudou muito desde que esta questão foi enquadrada, e o novoguias são muito melhorados. EmberJS surgiu com convenções (como Rails) e o MVC está muito mais bem definido agora.

Alguém ainda confuso deve ler todos os guias e assistir alguns vídeos:Seattle Ember.js Meetup

No momento, estou atualizando meu aplicativo paraEmber.js 1.0.0-pre2.