none
capas RRS feed

  • Pregunta

  • hola foro :


    Tengo la siguiente problematica 

    Tengo una aplicación asp.net con las siguiente capas : (Todos los proyectos comparten todas las capas . son 2 proyectos y uno por agregarse).

    -clases de dominio en un proyecto classlibrary dominio  para varios proyectos
    -clases de servicio en un proyecto  classlibrary servicio  para varios proyectos
    -capa presentacion para varios proyectos(mismo site) , si es la misma aplicacion por ende la base de datos es la misma.
    )
    Con este esquema planteado: Si cambio una clase del dominio existente puedo romper los servicios y  paginas que ya esta funcionando en presentacion,ademas de las tablas de la bd.

    El problema mas importante  es que algunas clases de negocio son compartidas , se puede mantener una clase de negocio original y despues tener un shared as link en otro lado.

    Que estrategia podría usar para poder realizar cambios sin afectar o evitar el mínimo impacto en los demás proyectos. por ejemplo con las clases de dominio comues (de presentacion ni hablar)

     (Comente en  algo este hilo tambien :

    otro hilo )

    Gracias desde ya

     

    jueves, 12 de marzo de 2015 17:04

Respuestas

  • >>El problema mas importante  es que algunas clases de negocio son compartidas , se puede mantener una clase de negocio original y despues tener un shared as link en otro lado.

    cuando dices clase de negocio te refieres a que esta en el proyecto de servicio, no?

    no entiendo que es esto de "compartidas" ? podrias crear un proyecto de negocio (servicio) separado para esta funcionalidad y referenciarla desde dodne lo necesites

    >>Si cambio una clase del dominio existente puedo romper los servicios y  paginas que ya esta funcionando en presentacion

    porque deberia suceder esto ? si pasa es porque el diseño de clases y metodos esta mal confeccionado

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    • Marcado como respuesta sebastian viga jueves, 12 de marzo de 2015 23:22
    jueves, 12 de marzo de 2015 17:12
  • Estimado sebastian viga

    Bienvenido al problema "de modificaciones en apps" ;)... 
    Si... todos tenemos ese problema que si modificas alguna clase (cualquiera sea) o métodos por ejemplo en su interfaz(no en su compartamiento) obviamente se "rompera" en donde se utilizan o consumen.
    Lo bueno que si realizas tu desarrollo basado en TDD detectaras donde se rompe para solucionar... 

    Pero bueno que pasa si los servicios deben "convivir" la version1 con la version 2 ¿?
    Esto me hizo acordar WCF

    Y la idea es la misma, tener versiones de tus servicios, de tu s API's... 
    ( y en consecuencia el costo de mantener las versiones funcionando.. tanto para desarrollar como para mantenerla en producción) mira tanto es mantener que servicios como twitter, facebook.. nos dan FECHA LImite para cambiar a utilizar la version XX de sus API ;)
    Bueno.. si tienes una capa de servicio tendrias ya que plantearte una metodologia o arquitectura para las versiones de los servicios .
    LA idea que la version1 del servicio tenga obviamente una capa que utiliza (entiddades por ejemplo) compatible con dicha version, y asi cada version del servicio

    Algunas "mejores practicas" (serguramente buscando encontras mas)

    Esto es lo que necesitas?

    Espero que te sirva de ayuda o guia


    Jose. A Fernandez | blog: http://geeks.ms/blogs/fernandezja

    • Marcado como respuesta sebastian viga jueves, 12 de marzo de 2015 23:21
    jueves, 12 de marzo de 2015 17:19
  • >>son clase del dominio y se usan en varios proyectos esas mismas clases

    entonces el dominio es la capa de negocio ? y se usa en varios servicio

    >>pero creo que hay que aceptar el impacto y cambiar en todos los proyectos o paginas  donde impacte esa clase. 

    en realidasd depende como defines esos objetos, si usas herencia y sobrecarga podrias generar funcionalidad que soporte lo nuevo y lo viejo

    no digo que sea algo facil de lograr, pero se podria

    aunque si puedes analizar el cambio a todos los proyectos quedaria mas prolijo


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    • Marcado como respuesta sebastian viga jueves, 12 de marzo de 2015 23:29
    jueves, 12 de marzo de 2015 17:44

Todas las respuestas

  • >>El problema mas importante  es que algunas clases de negocio son compartidas , se puede mantener una clase de negocio original y despues tener un shared as link en otro lado.

    cuando dices clase de negocio te refieres a que esta en el proyecto de servicio, no?

    no entiendo que es esto de "compartidas" ? podrias crear un proyecto de negocio (servicio) separado para esta funcionalidad y referenciarla desde dodne lo necesites

    >>Si cambio una clase del dominio existente puedo romper los servicios y  paginas que ya esta funcionando en presentacion

    porque deberia suceder esto ? si pasa es porque el diseño de clases y metodos esta mal confeccionado

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    • Marcado como respuesta sebastian viga jueves, 12 de marzo de 2015 23:22
    jueves, 12 de marzo de 2015 17:12
  • Estimado sebastian viga

    Bienvenido al problema "de modificaciones en apps" ;)... 
    Si... todos tenemos ese problema que si modificas alguna clase (cualquiera sea) o métodos por ejemplo en su interfaz(no en su compartamiento) obviamente se "rompera" en donde se utilizan o consumen.
    Lo bueno que si realizas tu desarrollo basado en TDD detectaras donde se rompe para solucionar... 

    Pero bueno que pasa si los servicios deben "convivir" la version1 con la version 2 ¿?
    Esto me hizo acordar WCF

    Y la idea es la misma, tener versiones de tus servicios, de tu s API's... 
    ( y en consecuencia el costo de mantener las versiones funcionando.. tanto para desarrollar como para mantenerla en producción) mira tanto es mantener que servicios como twitter, facebook.. nos dan FECHA LImite para cambiar a utilizar la version XX de sus API ;)
    Bueno.. si tienes una capa de servicio tendrias ya que plantearte una metodologia o arquitectura para las versiones de los servicios .
    LA idea que la version1 del servicio tenga obviamente una capa que utiliza (entiddades por ejemplo) compatible con dicha version, y asi cada version del servicio

    Algunas "mejores practicas" (serguramente buscando encontras mas)

    Esto es lo que necesitas?

    Espero que te sirva de ayuda o guia


    Jose. A Fernandez | blog: http://geeks.ms/blogs/fernandezja

    • Marcado como respuesta sebastian viga jueves, 12 de marzo de 2015 23:21
    jueves, 12 de marzo de 2015 17:19
  • gracias  por responder genios .

    Leandro son clase del dominio y se usan en varios proyectos esas mismas clases. El tema que va  a venir un cambio o solicitud de cambio en uno de los proyectos donde toque alguna de esas clases y va a romper lo que esta hecho en los demas proyectos a eso me referia,pero creo que hay que aceptar el impacto y cambiar en todos los proyectos o paginas  donde impacte esa clase.  

    jose muy buena idea, de versionar por servicios . Por lo que veo hay que manejar branch por version. Tendria que leer en detalle  analizar lo que pasaste 

    Gracias a los dos again

    jueves, 12 de marzo de 2015 17:39
  • >>son clase del dominio y se usan en varios proyectos esas mismas clases

    entonces el dominio es la capa de negocio ? y se usa en varios servicio

    >>pero creo que hay que aceptar el impacto y cambiar en todos los proyectos o paginas  donde impacte esa clase. 

    en realidasd depende como defines esos objetos, si usas herencia y sobrecarga podrias generar funcionalidad que soporte lo nuevo y lo viejo

    no digo que sea algo facil de lograr, pero se podria

    aunque si puedes analizar el cambio a todos los proyectos quedaria mas prolijo


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    • Marcado como respuesta sebastian viga jueves, 12 de marzo de 2015 23:29
    jueves, 12 de marzo de 2015 17:44