extjs - full - sencha download

Estructura del proyecto del mundo real con Sencha Architect

Question

Soy nuevo en Sencha ExtJS y Architect MVC, pero conozco MVC y algunas otras bibliotecas de JQuery en general.

Quiero preguntar al construir un sistema del mundo real, ¿cuál es el enfoque adecuado para diseñar una estructura de aplicación Sencha en Architect 2?

Por ejemplo, tenemos los siguientes departamentos en nuestra aplicación, ellos tienen distintas funcionalidades:

Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...

Enfoque 1: escríbalos en diferentes proyectos de Sencha Architect. Coser con la página de diseño principal + área principal + encabezado / pie de página + páginas de la barra lateral. (usando MVC.NET en nuestro caso)

--- Pros:

• Múltiples programadores pueden trabajar en diferentes subproyectos en un entorno ágil.

• Cada proyecto es más pequeño y más fácil de actualizar o reemplazar.

--- Contras:

• Tenemos diferentes proyectos de Sencha Architect para, por ejemplo, áreas principales, barra lateral, encabezado y pie de página. ¿Cómo colaboran entre ellos? Ahora solo usamos JQuery para pasar información entre ellos, pero se siente un poco hacky.

Enfoque 2: escríbalos en un gran proyecto de arquitecto Sencha. Por lo tanto, aparece en una sola página app.html con todo lo que contiene.

--- Pros:

• Ahora todos los componentes del proyecto pueden colaborar entre ellos.

• Una verdadera aplicación todo en uno de aplicación de una sola página se ve bien.

--- Contras:

• Tener dificultades si varios programadores están trabajando en un proyecto de Sencha Architect.

• Es una gran pieza complicada de la aplicación. Aunque está separado en categorías simples de aplicaciones, tiendas, M, V, C, pero podemos tener un bloqueo de nombre en los componentes de un proyecto más grande.

• La velocidad de carga puede ser un problema? Estoy adivinando aquí porque no sabemos si el diseño de Sencha Architect MVC carga ventanas y componentes relevantes, parte por parte o todo junto.

La pregunta es, si tomamos el primer enfoque, ¿cómo hacemos las comunicaciones entre los diferentes proyectos? Si tomamos el segundo enfoque, ¿Sencha Architech 2 está diseñado para construir proyectos del mundo real de esa manera? apilando todo en un gran proyecto?

Answer 1

Primero diré que estás pensando sobre este problema en todas las formas correctas. Tus pros y contras son acertados.

Segundo para la revelación completa, soy ingeniero en el equipo de Sencha Architect.

Mi sugerencia es tener proyectos separados que estén más relajados y quizás conectados por una aplicación de portal / tablero. La aplicación de pegamento se puede escribir en cualquier cosa, incluido Ext JS en Architect.

La razón por la que digo esto es simplemente que no me gusta poner todos mis huevos en una sola canasta y si has construido aplicaciones de una sola página sabrás que cuando están trabajando realmente zumban. Pero cuando ocurre una excepción javascript no capturada, puede obligar a ese usuario a tener que hacer una actualización completa para volver a un estado feliz. Por supuesto, si eres perfecto, esto nunca sucederá: p ¿Quién es perfecto?

Construyo Architect, que de hecho es una aplicación de una sola página muy grande. Como equipo, todos hacemos nuestro mejor esfuerzo para mantener a cada sistema en condiciones de trabajar con la menor dependencia posible de cualquier otro sistema. Usamos cosas como eventos, pub / sub, adaptador y patrones de complementos, etc.

Estos sistemas están muy divididos en espacios de nombres y directorios separados que, como todo software, ayudan a los desarrolladores a compartimentar. El arquitecto no apoya completamente esta idea hoy. Sin embargo, con la convención puede acercarse. por ejemplo, HRController, HRNewEmployeeForm, HREmployeeGrid

Tener recursos humanos como una aplicación separada, sin embargo, le ofrece HR.EmployeeController, HR.NewEmployeeForm, suponiendo que el nombre de su aplicación es HR. Cada aplicación es un proyecto separado y también permite que el equipo de desarrollo sea más ágil en la forma en que se implementa. Mayor victoria.

Otros usuarios han adoptado este enfoque y uno de ellos grafica todos sus proyectos en conjunto utilizando un enfoque iframe gestionado http://www.sencha.com/forum/showthread.php?243179

Asp.Net MVC es otro buen enfoque y puede permitirte algunas características como autenticación de usuario, etc.

¡Espero que esto ayude!