Estoy haciendo una aplicación de emberjs bastante compleja, y la estoy vinculando a un backend de APIs.

Las llamadas a la API generalmente no están vinculadas a ningún modelo en particular, pero pueden devolver objetos de varios tipos en diferentes secciones de la respuesta, por ejemplo. una llamada a la API de Eventos devolvería eventos, pero también devolvería activos de medios y personas involucradas en esos eventos.

Acabo de comenzar con el proyecto y me gustaría obtener una guía experta sobre cómo separar las preocupaciones para tener una base de código fácil de mantener.

La forma en que me estoy acercando a esto es:

Modelos: esencialmente manejan registros con sus campos, y otras propiedades computadas. Sin embargo, los modelos no son responsables de hacer peticiones.p.ej. Individual, Evento, Foto, Post etc.Víveres: Son esencialmente cachés. Por ejemplo, uneventStore almacenaría todos los eventos recibidos desde el servidor hasta el momento (de solicitudes posiblemente diferentes) en una matriz, y también en un hash de eventos indexados porid.p.ej. Tienda individual, tienda de eventos, etc.Controladores: Se vinculan a un conjunto de llamadas API relacionadas, por ejemplo, eventsController sería responsable de buscar eventos o un evento en particular, o crear un nuevo evento, etc. 'Dirigiría' la respuesta a diferentesstores para su posterior recuperación. No conservan la respuesta una vez que se ha enviado a las tiendas.p.ej. eventsController, userSearchController etc.Puntos de vista: Están vinculados a una visión particular. En general, mi aplicación puede tener varias vistas en diferentes lugares, por ejemplo,latestEventsView en el Panel de control además de tener una página de eventos separada.Plantillas: son lo que son.

Muy a menudo, mis plantillas deben estar vinculadas directamente a las tiendas (por ejemplo,peopleView quiere enumerar a todos los individuos en la Tienda individual en una lista, ordenados por algún orden).

Y a veces, se unen a una propiedad computada.

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

Las diversas opciones de filtrado y clasificación 'elegidas' en la vista deben devolver diferentes listas de la tienda. Puedes ver mi última pregunta en¿Cuál es la manera correcta de cambiar entre varias opciones de filtrado?

¿Quién debería hacer este filtrado, la vista propia o las tiendas?

¿Es este tipo de enlace a través de capas bien, o un olor de código? ¿Es buena la separación de preocupaciones, o me estoy perdiendo algo? ¿No deberían los controladores hacer algo más aquí? ¿Deben mis vistas enlazar directamente a las tiendas?

¿Algún caso especial particular de MVC más adecuado a mis necesidades?

Actualización 17 abril 2012 Mi investigación continúa, particularmente desdehttp://vimeo.com/user7276077/videos yhttp://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html yhttp://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Algunos problemas con mi diseño que he descubierto son:

controladores que realizan solicitudes (tiendas o modelos o algo más debería hacerlo, no controladores)Faltan los gráficos de estado: son importantes para las interacciones entre la vista y el controlador (después de que en algún momento te das cuenta de que tus interacciones no son más simples)

Este es un buen ejemplo de gráficos estatales en acción:https://github.com/DominikGuzei/ember-routing-statechart-example

ACTUALIZACIÓN 9 DE ENERO DE 2013

Sí, ha pasado mucho tiempo, pero esta pregunta últimamente está recibiendo muchas visitas, y es por eso que me gustaría editarla para que la gente tenga una idea.

El paisaje de Ember ha cambiado mucho desde que esta pregunta fue enmarcada, y el nuevoguias Se han mejorado mucho. EmberJS ha creado convenciones (como Rails) y el MVC está mucho más definido ahora.

Cualquiera que aún esté confundido debería leer todas las guías y ver algunos videos:Meetup de Seattle Ember.js

En este momento, estoy actualizando mi aplicación aEmber.js 1.0.0-pre2.