Bufff!!! Esto sí que me da qué pensar :P Gracias de nuevo y me sumo a la petición (que espero enriquecer en breve...) sobre que se promueva el comentario de diferentes métodos de organización de las aplicaciones.
En fin, que esto de la POO es un mundo vastísimo lleno de posibilidades :P ------------------------------------- CROMA2 Carlos Terradillos Gutiérrez Diseño [web·multimedia·gráfico] Http://www.croma2.com/ [EMAIL PROTECTED] > -----Mensaje original----- > De: Joseba Alonso [mailto:[EMAIL PROTECTED] Enviado el: lunes, 04 de > diciembre de 2006 13:28 > Para: [EMAIL PROTECTED] > Asunto: RE: [ASNativos] Organización de MVC > > > > Por otro lado, no entiendo muy bien que por ejemplo, si la primera > > "escena" > > tiene el login, el mvc/escena deba gestionar únicamente el > login ¿no > > es aceptable que también gestione el paso a la escena siguiente? ¿o > > debe gestionar un cometido estrictamente en aras de la claridad > > conceptual de cada clase? Porque por otro lado, en esa > escena también > > hay un panel de información, se cargan dinámicamente datos de la > > aplicación que tienen una correspondencia visual (identidad > > corporativa, báners...) ¿debería hacer clases para cada cosa? > > Hombre, la estructuracion de clases, sobre todo cuando estas > aprendiendo, es algo muy personal, el probar diferentes > configuraciones te dará la clave para tu "metodo perfecto" > pero en el caso del "login" gestionando el paso al estado siguiente > tiene algunos problemas que te puedo ir adelantando. Lo primero, la > gestion de cambio de estado puede implicar muchas cosas que pueden > necesitar todos los cambios de estado en cualquier parte, por ejemplo, > un preload, un cambio de titular, la selección de un elemento del menu > principal...etc. Toda esa gestion seria mucho más eficiente y menos > liosa en el controlador "padre", porque según vas avanzando en el > proyecto es muy posible que el cambio de estado implique cada vez mas > y mas cosas. > Por ejemplo imaginate que mas tarde pones la opcion de "recordar > usuario", en ese caso la proxima vez que se inicie, ya no necesitarias > cargar el estado de login, sino que pasarias directamente al > siguiente... > > Tambien esta lo que dices de la claridad conceptual de la clase, a mi > no se me ocurriria más tarde buscar el codigo que hace el cambio de > los diferentes estados del usuario dentro uno de los estados. Este > deberia preocuparse solo de si mismo, no del resto de estados. > > > > > > Yo lo que suelo hacer es que reservo clases digamos de > gestión de la > > aplicación y hago otras (normalmente extienden > > MovieClip) para cuestiones visuales de intractividad o animación y > > normalmente son muy simples. De estas últimas puede haber > muchas y no > > me importa demasiado pero de las primera, estoy más cómodo si son > > pocas. Quizá no es la opción más ortodoxa y finalmente es mejor ser > > estricto con la metodología de clases que gestionen problemas muy > > concretos pero esa es una meta por alcanzar... > > > Yo normalmente, en web normales (no muy complicadas) suelo > hacer casi seguro > 5 grupos de clases: > > Clases de control: Controladores para las vistas. Son > Singletons, es incompatible tener dos clases controlando la > misma cosa. > > Clases de vista: Representan los diferentes estados del > usuario, normalmente corresponden a las secciones de la web > excepto una, la principal que corresponderia al "todo", el > MovieClip principal. Todas estas clases las hago extender de > MovieClip, esto ya es una preferencia muy personal mia, mi > "framework" personal esta contruido asi, hay gente que usa > composicion. > > Clases de servicio: La capa de acceso a datos. Se encargan de > leer ficheros XML, hacer peticiones al servidor..etc. > Normalmente las usan las clases de modelo. > > Clases de modelo: La logica de la aplicación, usan las clases > de servicio para obtener y almacenar la información. > > Clases de UI: Son las clases que controlan los diferentes elementos de > interface: botones, menus, scrolles, visores de medias...etc. > Si su funcionalidad es más complicada, los separo en otro MVC. > > Normalmente se inician de la siguiente manera: > > Lo primero se inicia el view principal, esto es así porque > esta directamente colocado en la linea de tiempo. Consigue > una referencia a su controlador por el metodo del singleton y > llama a 2 metodos: Uno registerView() para que el controlador > tenga una referencia a la vista y (si es necesario) instancie > el modelo y se lo pase de vuelta a la vista. Y luego llama a > uno initialize() que inicializaria la aplicación principal, > por ejemplo, para cargar la primera seccion. Esta a su vez > sigue el mismo proceso, se instancia la vista (con un > attachMovie, loadMovie o un gotoAndStop), consigue la > referencia a su controlador y lo inicializa. En esa vista de > la seccion, pueden ocurrir 2 tipos de eventos probocados por > el usuario: eventos que maneja el controlador de esa vista o > eventos que el controlador de esa vista no puede manejar y > pasa al controlador de aplicación, como por ejemplo, el > cambio a otra seccion. > > De todas maneras, como he dicho al principio, esta es *mi* > metodologia, probablemente esto pueda cambiar en el modo que > montan las aplicaciones otras personas. Lo mejor es que tu > mismo vayas probando unas y otras y te quedes con la que mas te guste. > > Por cierto, estaria bien si algun otro comenta como lo monta > el, siempre es bueno tener más puntos de vista :) > > Un saludo, > > Joseba Alonso > www.5dms.com > www.sidedev.net > J > > > __________ Información de NOD32, revisión 1899 (20061204) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > > ----------------------------------------------------- ASNativos www.5dms.com subscripciones/desubscripciones http://asnativos.5dms.com -----------------------------------------------------
