2005/10/5, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Entonces, el SessionComposite tiene una Session que hace el #add:, #remove: > , etc ya sea en Memoria, Omni, en Re, o etc. > A su vez cada subclase de SessionComposite sabe utilizar a la session para > realizar las tareas que le corresponden, alta, baja, busqueda, etc.
Esto de los composites no lo catzo. Tal vez por la palabra "composite", que no la asocio al tema en cuestión. > Lo que hace el SessionComposite es pedirle el objeto correspondiente a > AtomicComposite, > y el SessionComposite sabe realizar la tarea de #add:, etc sobre este objeto. > En AtomicComposite esta la view correpondiente a cada objeto del dominio. > EdditingObjectPresenter sabe utilizar a AtomicComposite para editar objetos. > Despues si estas trabajando contra un Server en memoria --> los objetos estan > en memoria, si haces: > myBankServer becomeReStore. > Ahora es un ReStoreServer, cada session creada por SessionComposite sera > persistida en una BD. > No hay que hacer ningun cambio. Ah... los composites son presenters... composite.:-) Osea que todo el tema de la sesión lo maneja el presenter. > Con este tipo de delegacion queda un 95% transparente. Hay que tocar cosas > pero pocas. > El #markDirty: (se detecta automaticamente), esta metido en los Conectores > de AtomicComposite. Sigo sin saber que son los conectores.:-/ Todo lo que me viene a la cabeza son los de VAST, pero poco tienen que ver aqui. > Al hacer esto cuando haces los TestCase tenes que tener en cuenta el > #markDirty:, > ya que cuando pasas de un ImageServer a un OmniBaseServer hay que mandar > el #markDirty:. Graficamente esta solucionado, pero a nivel de modelo no. > --> cuando creas los TestCase tenes que poner el #markDirty, y cuando trabajas > con inspectores y esas cosa sobre un OmniBaseServer tenes que acordarte del > #markDirty. Claro, porque lo resuelve "otro" y no el mismo modelo. > Estas 2 son las unicas desventajas que encontre hasta ahora. Totalmente > solucionables, > mas la primera con el Code Rewriter del D6. > Se pueden encontrar patrones para aplicar transformaciones del codigo, para > pasar del 90 o 95% al 99,9%. > Classes como (AddPatientComposite) son para especializacion del comportamiento > para contemplar casos especiales. > Tiene por lo general de 2 a 4 metodos sumamente cortos. Hehe, bien podría darse el caso de tener una homónima, tambien tengo Patient's :-) > De esta manera combinas la herencia (jerarquias) con delegacion (jerarquias > paralelas colaborando), que es un forma que me ha dado muy buenos resultados. Bueno, veré, pero tal vez el ODBSession es la pieza que me estaba faltando para ocuparse de todo esto. -- Esteban A. Maringolo [EMAIL PROTECTED]
