Ir al contenido


Foto

Cliente (.exe) que conecta a Firebird


  • Por favor identifícate para responder
21 respuestas en este tema

#1 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 02 febrero 2016 - 07:44

Hola, me gustaria saber como manejan la actualización de los .exe en los casos donde se debe si o si, actualizar cada de las PCs que conecta a Firebird.

El caso puntual que tengo es un cliente con 9 PCs donde cada vez que actualizo una nueva version (.exe) lo copio en cada una de ellas, lo que es bastante engorroso.

 

gracias


  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 02 febrero 2016 - 08:33

Yo todavía no tuve cliente así por lo que no te sabría decir mucho.

Hace un tiempo había escuchado sobre un utilitario que permite justamente instalar, configurar, y creo que hasta "clonar" un entorno, en varios equipos a la vez. Tengo que admitir que al día de hoy no recuerdo como se llamaba, y tampoco me hago a la memoria en como es que funcionaba realmente.

La cosa es que lo que hacía en un equipo, luego era replicado en los demás equipos de la red.

Si recuerdo el nombre, o lo encuentro, lo pongo acá.

 

La otra posibilidad es que eso pase a cuenta del cliente. Es decir que el mismo, o sus usuarios, se tomen el trabajo de cambiar el exe. Tu puedes dar una clase a modo de soporte (obviamente te tienen que pagar por ello) a algunos del personal y luego que ellos mismos tomen el trabajo en sus manos. Yo recomiendo hacer un instructivo o manual para que lean y se familiaricen. Si es cosa de reemplazar unicamente el exe es una actividad trivial, que yo considero que hasta la persona más neófita puede llevar a cabo.

Si yo estuviera en tu caso y no queda otra que deba tomar en mis manos todo ese trabajo, le cobro un buen extra por dicho soporte. Las cosas como son. Todo se traduce en el señor billetín. Lleva tiempo, el tiempo es dinero. Tiempo que podría estar destinando en la nueva versión, o atendiendo un nuevo cliente, etc.

 

También soy de la idea de que todo emprendimiento que tenga más de 3 PCs en red y montado un C/S en funcionamiento cuente con alguien de formación Informática o Sistemas para que justamente se encargue de mantener las cosas más o menos ordenada. No lo digo con la intención de desligarnos de responsabilidades, sino más bien para que tengan a alguien que les esté dando respaldo hasta el momento en que nos podamos hacer cargo. Supongamos que justo nos llama un cliente un Viernes a las 23hs diciendo que el server mientras hacía el arqueo de caja hizo un ruido raro y no encendió más, nuestro negocio ha cerrado ya, estábamos durmiendo, en la otra parte de la ciudad, o de viaje. ¿Le decimos que se la aguante hasta el Lunes? Si tuviera a alguien dedicado en su empresa que pudiera en el momento saber diagnosticar si se ha comprometido el Server o no podrá estar más dispuesto a una posible respuesta del tipo "Espere al Lunes que voy y lo asisto a primera hora". Es muy importante en estos casos definir claramente las competencias de cada quien.  Además cuanto más clientes tengamos, y cuanto más sean los usuarios llega un punto en el que no es viable, física ni económicamente dar el debido soporte de forma extendida.

 

Saludos,


  • 1

#3 pcicom

pcicom

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 267 mensajes
  • LocationMéxico

Escrito 02 febrero 2016 - 10:23

Saludos Nikolas..

 

Puedes utilizar un metodo simple, el cual consiste en un LANZADOR de tu APLICACION, el cual primeramente checa la version de un equipo servidor y la compara con la de la PC desde un archivo .ini que deben de tener la aplicacion..

 

Si la version es diferente copia/descarga el .exe de la aplicacion del servidor de red/ruta compartida/web etc.. y actualiza el INI con la version nueva,,   

 

De esta manera solo basta con actualizar en un equipo/unidad de red/wervidor web el .exe y el .ini con la informacion del sistema..

 

Espero haberte dado una idea..

 

Actualmente asi lo manejo para redes con unca cantidad promedio de 10 equipos,  en 2 empresas tengo 25, equipos e inmediatamente cuando pongo la actualizacion, todas se actualizan sin problema alguno..

 

SALUDOS..


  • 1

#4 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 03 febrero 2016 - 06:06

Saludos Nikolas..

 

Puedes utilizar un metodo simple, el cual consiste en un LANZADOR de tu APLICACION, el cual primeramente checa la version de un equipo servidor y la compara con la de la PC desde un archivo .ini que deben de tener la aplicacion..

 

Si la version es diferente copia/descarga el .exe de la aplicacion del servidor de red/ruta compartida/web etc.. y actualiza el INI con la version nueva,,   

 

De esta manera solo basta con actualizar en un equipo/unidad de red/wervidor web el .exe y el .ini con la informacion del sistema..

 

Espero haberte dado una idea..

 

Actualmente asi lo manejo para redes con unca cantidad promedio de 10 equipos,  en 2 empresas tengo 25, equipos e inmediatamente cuando pongo la actualizacion, todas se actualizan sin problema alguno..

 

SALUDOS..

 

Recuerdo un colega quien lo soluciono de la forma que comentas, pareciera ser la manera de hacerlo.

La unica traba que veo, es que no tengo un lanzador, el programa es un solo .exe y la dificultad para copiarse con el mismo nombre.

Vere como lidiar con ese tema.

 

gracias a ambos por sus comentarios.


  • 0

#5 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 03 febrero 2016 - 06:37

Saludos.

 

Puedes "fabricar un lanzador" que verifique la versión al iniciar el SO, claro sería instalar dicha aplicación conjuntamente con tu sistema cada nuevo equipo que entre a formar parte de la "red".

 

También puedes usar el Active Directory si esta montado.


  • 1

#6 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 03 febrero 2016 - 07:24

La idea del Launcher, tan de moda ultimamente sobre todo en los videos juegos, puede resultar muy conveniente como un desafío. Si el cambio de una versión a otra no es traumático y es simplemente descargar el exe y reemplazarlo o a lo sumo algunas pocas dll y/o otros archivos puede resultar un tanto fácil preveer como encarar el desarrollo del Launcher. Ahora bien si resulta ser que los cambios de versión son bastantes y complejos, el Launcher puede quedar Obsoleto en pocas versiones y deberá cambiarse en la medida en que salen nuevas versiones.

 

Es decir que mientras se pueda encontrar un "denominador común" predecible que permita determinar el paso de una versión a otra el Launcher puede ir soportando y detectando estas nuevas versiones, todo bien y nos hace la vida más sencilla. En cuanto aparezca un cambio fuera de lo esperado, ya no sólo deberás cambiar el exe sino que también el Launcher. ¡Y eso es doble trabajo! Trabajo que se traduce en tiempo, y el tiempo en dinero.

 

Debe pensarse seriamente esto. Hacer un estudio realista del rumbo que se tiene previsto sobre el ciclo de vida de nuestro proyecto. De ese modo uno puede al menos tener una noción del impacto del crecimiento del software y diseñar de la mejor manera el Launcher para que pueda al menos hacernos menos traumática los cambios.

Por ejemplo: Supongamos que la versión 1.0 de nuestro soft depende de una biblioteca de terceros, asi que diseñamos el launcher para que descargue los archivos de esta basados en la confianza en que el nombre de dichos archivos no cambian y que su equipo de desarrollo es predecible y preparado para una labor de reingeniería lo más "plana". Para la versión 1.5 nos actualizamos a una nueva versión de esta biblioteca y nos damos con que los archivos fueron renombrados, y que ahora son muchos más. Obviamente el Launcher habrá que volver a diseñar.

Imagina que cada vez que damos un paso más sobre nuestro soft nos encontramos con más cambios que rompen el Launcher. El remedio se nos convirtió en la enfermedad.

 

Les pongo un caso de uso real: Minecraft cambió 3 veces el Launcher desde el paso de la versión 1.5 a la 1.8. Fueron cambios muy grandes, no se dejen engañar por esos .5 y .7 que uno piensa en cambios "menores". Para la versión 1.8 hicieron un mejor estudio de avance y el Launcher maduró lo suficiente como para prever las formas de absorver y soportar multiples versiones del juego y preparar la cancha para 1.8, y 1.9+

 

No es mi intención desmerecer el sistema de Launchers. Son una buena alternativa. Sólo quiero destacar que ES OTRO SISTEMA más que estará a nuestro cargo y DEPENDEDIENTE del avance de como se van dando los cambios. No hay que confiarse ciegamente en que "Ba, si mi soft es unicamente un exe y ya está" porque cuando ya no sea unicamente esto y nos enfrasquemos en el "¿Y ahora?"

 

Saludos,


  • 1

#7 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 03 febrero 2016 - 08:23

Yo tambien tengo ese problema

 

La forma mas sencilla? No hay que programar cliente/servidor

 

Hacer un "actualizador", un launcher que bajen de un ftp/dropbox/etc un exe y lo reemplaze es coser y cantar. Si se necesitan distribuir mas archivos o hacer cosas "mas raras", lo metes todo adentro de un paquetito Inno Setup.

 

Yo uso esta tecnica en un escenario en donde la aplicacion es monousuario y trabaja con una basecita SQLite; dicha base la puede crear perfectamente mi programa si no existe (todas las tablas completas), dispongo de una clase para ello. Al actualizar, si ya tenia una base, creo otra temporal y la comparo con la que ya tenia (tabla por tabla, campo por campo)

 

Peeero, como realizas actualizaciones SQL en un "servidor", en donde 15 pc comparten el mismo exe; quien las hace??? El que baja primero el exe? Try/except si falla la sentencia porque "la tabla pedrito ya existe"?

 

Si se programa en capas es mucho mas sencillo, porque las aplicaciones clientes son mucho mas sencillas, de hecho son hasta "bobas": llaman metodos que expone el servidor y muestran resultados, no hacen nada raro

 

El modelo de meter el mismo exe (cliente / servidor) en cada pc es realmente un dolor de coj..

 

Lo bueno de programar en capas es que si se actualiza el servidor para corregir/cambiar un metodo, siempre y cuando la firma (nombre y lista de parametros) sea la misma, no te implica tener que actualizar todos los clientes! Se propaga todo "por arte de magia"

 

Aun asi, hay casos en los que hay que actualizar los clientes porque se agrego funcionalidad por ejemplo. Para estos casos yo sigo pensando que la mejor forma es que el servidor maneje a los clientes; el servidor puede disponer tranquilamente de un metodo que reciba tu version del ejecutable y te diga si tenes que actualizar o no, y que te devuelva el "nuevo exe". Y para los casos de que hay que instalar bibliotecas de terceros, vuelvo a reiterar la opcion de meter todo el paquete dentro de un installer como Inno Setup, y te olvidas de todos los problemas; cualquier usuario, hasta el mas ignaro puede apretar 3 o 4 veces seguidas y sin pestañar, "siguiente"


  • 2

#8 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 03 febrero 2016 - 09:32

Yo tambien tengo ese problema

 

La forma mas sencilla? No hay que programar cliente/servidor

 

Hacer un "actualizador", un launcher que bajen de un ftp/dropbox/etc un exe y lo reemplaze es coser y cantar. Si se necesitan distribuir mas archivos o hacer cosas "mas raras", lo metes todo adentro de un paquetito Inno Setup.

 

Yo uso esta tecnica en un escenario en donde la aplicacion es monousuario y trabaja con una basecita SQLite; dicha base la puede crear perfectamente mi programa si no existe (todas las tablas completas), dispongo de una clase para ello. Al actualizar, si ya tenia una base, creo otra temporal y la comparo con la que ya tenia (tabla por tabla, campo por campo)

 

Peeero, como realizas actualizaciones SQL en un "servidor", en donde 15 pc comparten el mismo exe; quien las hace??? El que baja primero el exe? Try/except si falla la sentencia porque "la tabla pedrito ya existe"?

 

Si se programa en capas es mucho mas sencillo, porque las aplicaciones clientes son mucho mas sencillas, de hecho son hasta "bobas": llaman metodos que expone el servidor y muestran resultados, no hacen nada raro

 

El modelo de meter el mismo exe (cliente / servidor) en cada pc es realmente un dolor de coj..

 

Lo bueno de programar en capas es que si se actualiza el servidor para corregir/cambiar un metodo, siempre y cuando la firma (nombre y lista de parametros) sea la misma, no te implica tener que actualizar todos los clientes! Se propaga todo "por arte de magia"

 

Aun asi, hay casos en los que hay que actualizar los clientes porque se agrego funcionalidad por ejemplo. Para estos casos yo sigo pensando que la mejor forma es que el servidor maneje a los clientes; el servidor puede disponer tranquilamente de un metodo que reciba tu version del ejecutable y te diga si tenes que actualizar o no, y que te devuelva el "nuevo exe". Y para los casos de que hay que instalar bibliotecas de terceros, vuelvo a reiterar la opcion de meter todo el paquete dentro de un installer como Inno Setup, y te olvidas de todos los problemas; cualquier usuario, hasta el mas ignaro puede apretar 3 o 4 veces seguidas y sin pestañar, "siguiente"

 

Por diseño en capas te refieres al esquema que ofrece DataSnap, ¿el gran ex MIDAS?

¿O a ese enfoque en el que se diseña por un lado una aplicación servidor que hace de intermediario entre la aplicación cliente y la base de datos?

Aunque no se si estoy seguro de de si DataSnap es justamente lo mismo que decir 3-Niveles.

 

Hasta donde yo recuerdo el esquema de dividir las aplicaciones de esa forma se lo llama Aplicaciones de 3 Niveles (que no capas), y ya más en general se habla de aplicaciones N-tier. Y también se popularizó el término de cliente delgado o liviano o "thin-client" en inglés.

Si es que los conceptos que me dieron en la universidad no los tengo oxidados.... ;) <_<

 

El desarrollo en capas es otra cosa. Surje del patrón Layers. Que sugiere encarar el desarrollo de una aplicación por capas "o módulos" dirían algunos. El concepto más básico es el de 3 capas (que muchos confunden con el concepto de 3 Niveles): Lógica, Interfaz, Datos. Y más en general el concepto adquiere su forma N-Layers, y pueden aparecer capas como: Aplicación, Presentación, Dominio, Servicio Técnico, Base, entre otras.

 

Son conceptos independientes. Una aplicación puedes estar desarrollada en capas pero no ser N-tier, o a la inversa. Como a su vez, puede ser N-tier y ser desarrollada en capas.

 

Yo tengo pendiente estudiar el paso hacia el esquema en Niveles, en Lazarus desconozco cual será el equivalente al DataSnap de Delphi... si es que lo tiene. :(

 

Saludos,


  • 0

#9 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 03 febrero 2016 - 11:04

Osea que una cosa es la arquitectura de la aplicacion... la de tres niveles es la mejor. Datos procesos y clientes
Y otra cosa son los modulos o capas de desarrollo.
Pero a lo que se refiere agustin es que el ser cliente servidor es como tener el disco compartido. El famoso disco conpartido donde hay un archivo dbf access paradox... y todos los clientes actuan sobre el mismo. Teniendo un motor como mysql o firebird cambia la cosa... pero este problema no se soluciona.. ea decir el tema de la version requiere si o si un servidor para comprobar la actual y la ultima y tambien para descargar la actualizacion.. porque permitw centralizar la tarea.
Saludos

Enviado desde mi SM-G530M mediante Tapatalk
  • 0

#10 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 03 febrero 2016 - 11:41

Osea que una cosa es la arquitectura de la aplicacion... la de tres niveles es la mejor. Datos procesos y clientes
Y otra cosa son los modulos o capas de desarrollo.
Pero a lo que se refiere agustin es que el ser cliente servidor es como tener el disco compartido. El famoso disco conpartido donde hay un archivo dbf access paradox... y todos los clientes actuan sobre el mismo. Teniendo un motor como mysql o firebird cambia la cosa... pero este problema no se soluciona.. ea decir el tema de la version requiere si o si un servidor para comprobar la actual y la ultima y tambien para descargar la actualizacion.. porque permitw centralizar la tarea.
Saludos

Enviado desde mi SM-G530M mediante Tapatalk

 

mezclaste todo o lo escribiste de una manera que asi lo entiendo yo, jeje

El problema radica en que forma actualizar los ejecutables en un sistema de red.

Ejemplo:

 

Pc1  con version1

Pc2  con version1

Pc3  con version1

creo la version2, entonces ¿cual seria la mejor manera de hacer lo siguiente?

Pc1  con version2

Pc2  con version2

Pc3  con version2

 

osea, actualizar todas las Pcs a la nueva version creada.


Editado por Nikolas, 03 febrero 2016 - 11:42 .

  • 0

#11 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 03 febrero 2016 - 11:44

mezclaste todo o lo escribiste de una manera que asi lo entiendo yo, jeje
El problema radica en que forma actualizar los ejecutables en un sistema de red.
Ejemplo:

Pc1 con version1
Pc2 con version1
Pc3 con version1
creo la version2, entonces ¿cual seria la mejor manera de hacer lo siguiente?
Pc1 con version2
Pc2 con version2
Pc3 con version2

osea, actualizar todas las Pcs a la nueva version creada.

Es que sino es manual... necesitas um servidor que lo informe supongo yo seria una manera... el otro tema lo hable porque los otros muchachos lo comentaron...
Se me ocurre sini podriad tener los ip de kas maquinas que deberiab ser estaticos... y luego enviar un mensaje a esos ips...

Enviado desde mi SM-G530M mediante Tapatalk
  • 0

#12 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 03 febrero 2016 - 04:35

Es correcta la distinción que hace Delphius; se me cruzaron los cables entre el tier y el layer

Yo me refería al primero, a diseñar en niveles, de forma tal que los procesos y la persistencia se definen en un servidor y expone sólo una API que los clientes pueden consumir

Saludos
  • 0

#13 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 05 febrero 2016 - 05:48

¿ No se podía hacer todo desde el mismo ejecutable ?.

 

Es decir, en la base de datos Firebird mantener unos campos para el ejecutable : fecha, tamaño, nº versión y binario del ejecutable. Cuando lanzamos el ejecutable, comparamos el binario en ejecución con los campos de fecha, tamaño y nº versión almacenados en la base de datos, de forma que si el binario en ejecución es más moderno, actualizamos la base de datos, y si es más antiguo, reemplazamos el binario del equipo local.

 

La dificultad estriba en reemplazar el binario que se está ejecutando. Pero ello tampoco debería ser imposible. Simplemente guardamos en un archivo local el binario que tenemos en la base datos, después lanzamos un archivo .BAT (que podemos haber construido sobre la marcha) para reemplazar el/los archivos de la aplicación, y cerramos inmediatamente la aplicación para que el archivo .BAT tenga acceso a reemplazar el binario,

 

El archivo .BAT debería hacer un pequeño bucle de espera hasta que el programa no esté aún en ejecución. Una vez detecte que el programa ya no está en ejecución, reemplaza el binario antiguo por el nuevo, y finalmente de nuevo el nuevo binario ya actualizado.


php
  1. :bucle
  2. tasklist /fi "imagename eq MiPrograma.exe" |find ":" > nul
  3. if errorlevel 1 goto bucle
  4.  
  5. copy MiPrograma.new.exe MiPrograma.exe


  • 2

#14 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 05 febrero 2016 - 05:58

Tener las funciones del lanzador en el mismo ejecutable de la aplicación mantiene la sencillez de solo requerir un único ejecutable en cada cliente (ni siquiera el BAT de reemplazo de archivos es necesario que exista permanentemente, se puede generar y eliminar solo cuando se necesite.

 

Con este mecanismo puedes actualizar desde un único equipo cualquiera de la red, y los cambios se trasladan automáticamente al resto de PCs en el siguiente arranque de la aplicación.

 

Personalmente para mi aplicación tendría que hacer el mecanismo un poco más complejo para que también almacene en la base de datos, y actualize automáticamente, todos los archivos de la carpeta \Reports (son los archivos FastReports con las plantillas de informes), así como un pequeño puñado de librerías (fbclient.dll, dbexpint.dll, ...). Pero no veo porque no debería funcionar.

 

Solo me preocupa la propagación de virus. Si un virus modifica el ejecutable en un PC y le cambia el tamaño / fecha de modificación, entonces nuestro mecanismo de actualización lo detectará como una versión más moderna del ejecutable, y subirá ese ejecutable a la base de datos, actualizando todos los equipos en el siguiente arranque y propagando el virus a todos los PCs.


  • 1

#15 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 05 febrero 2016 - 01:24

gracias Marc. Aun no decido que hacer.

Habia pensado otra opcion:

-tener registro de los PATH de los equipos

-armar una carpeta en la PC servidor denominada UPDATE y de alli copiar a todas las PCs, solo tendria 2 trabas 1° que las PCs esten prendidas y 2° que no se este ejecutando el .exe

Esto apunta a modificar todos los archivos que sean la acualizacion (.exe,reportes,librerias,imagenes,carpetas internas,etc)


  • 0

#16 pcicom

pcicom

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 267 mensajes
  • LocationMéxico

Escrito 10 febrero 2016 - 08:14

Saludos NiKolas

 

Precisamente esa es la tarea del LAUNCHER descargar todo lo NECESARIO al detectar que la PC tiene desactualizado el EXE..

El launcher debe se ser capaz de:

 

* Comparar la Version Actual contra la NUEVA

SI ESTA DESACTUALIZADO
* Validar la version actual y comparla con la NUEVA Version
* Validar si existen MODIFICACIONES a la BD y Aplicarlas, descargando el codigo para EXECUTARLO en la BD
* Validar SI Existen NUEVOS Archivos que se requieren para ejecutar el EXE.

* Una vez realizado todo esto ACTUALIZAR la version a la mas reciente.

ESTA ACTUALIZADO

 

EXECUTAR EL EXE Principal de tu PROGRAMA.

 

Asu misma vez el .EXE debe de checar la version del LAUNCHER y en caso de no ser el ULTIMO descargar el NUEVO Lancher..
 

 

La tarea de crear el LAUNCHER es un poco tardada dependiento de tu tiempo y necesidades,  pero despues no veras NINGUNA COMPLICACION en hacer cualquier cambio y actualizar el SISTEMA..

Suerte.


  • 2

#17 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 10 febrero 2016 - 10:31

Yo sigo pensando que la mejor forma es que el server provea a los clientes de la version adecuada.

 

Ejemplo: los telefonos moviles; si google arregla algo en la red social Google+ no necesariamente tengo que actualizar "mi exe" en mi telefono; pero en cambio si agrega una funcion para buscar las fotos en donde..bla, bla, probalemente reciba automaticamente una actualizacion donde esta implementada dicha funcion

 

De esta manera se evita el lio de, desde una app cliente, "validar modificaciones en la BD y aplicar de ser necesario", lo cual es algo bastante peludo de implementar

 

Me resulta bastante feo que si tengo un error de logica de negocios o de acceso a datos "tener que actualizar todos los clientes"; ellos solo consumen una API. Esto obviamente nos aliviana las cosas a los desarrolladores y a la vez no molestamos tanto con "actualizar tantas veces" (triste realidad :))

 

Solo el server se encarga de actualizar la BD; el server provee a los clientes: version minima de ejecutable, y una funcion para obtener dicha version; y al conectar, bloquear al que no tiene la version adecuada (opcional obvio)

 

Creo que es el esquema mas simple y robusto que puede haber; la pega es que en una app cliente-servidor (ok, yo les llamo "cliente servidor", aca es muy comun ver programas implementados asi): una red de computadoras (lan, wlan, vpn, la que quieran) meten una base de datos en una pc, meten un ejecutable (delphi + forms + datamodule) y todos ejecutan el mismo exe. En estos casos de "cliente-servidor" no se puede implementar facilmente esta propuesta, la unica forma es diseñando aplicaciones multi-nivel (multi-tier)


  • 1

#18 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 11 febrero 2016 - 06:52

Yo te entiendo perfectamente Agustin. El enfoque que sugieres es quizá el más adecuado. Cuanto más delgados sean los clientes mejor.
El asunto es que Nikolas ya tiene un sistema desarrollado a "su estilo" y no creo que esté en condiciones de reescribir su proyecto bajo el esquema que propones. En todo caso puede ir preparando el camino para nuevas versiones.
Por el momento considero que la opción de un Launcher puede servir como transición hasta lograr un esquema maduro. Claro está, con los recaudos y teniendo presente las cuestiones que presenté.
Por cierto, en Android el sistema de actualizaciones se basa en el principio de Observer. Existe en service "escuchando" si hay nuevas actualizaciones disponibles en el server y de ser necesario actualiza.
Los clientes (apps) se me hace que no todas se implementan de forma delgada.

Saludos.
  • 0

#19 genriquez

genriquez

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 539 mensajes
  • LocationCali, Colombia

Escrito 11 febrero 2016 - 08:23

Obviamente el trabajar en 3 capas ayuda mucho a eliminar la necesidad de actualizar los .exe para muchas modificaciones donde solo se cambia la base de datos o algunos procedimientos que se ejecutan en el servidor, pero pasar de cliente/servidor a 3 capas, lleva algo de tiempo y esfuerzo, además de entender la otra filosofía, ya que cuando venimos de cliente/servidor a veces es difícil adaptarse.

 

De hecho gran parte de mi trabajo acá en Colombia consiste en asesorar a las empresas a llevar ese cambio, y casi todos los de sistemas son personas que llevan varios años programando.

 

Saludos.


  • 1

#20 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 11 febrero 2016 - 11:39

Yo sigo pensando que la mejor forma es que el server provea a los clientes de la version adecuada.

 

Ejemplo: los telefonos moviles; ......

 

Me resulta bastante feo que si tengo un error de logica de negocios o de acceso a datos "tener que actualizar todos los clientes"; ellos solo consumen una API. Esto obviamente nos aliviana las cosas a los desarrolladores y a la vez no molestamos tanto con "actualizar tantas veces" (triste realidad :))

 

Hola amigo Agustín

 

Yo veo el otro lado de la moneda, las app's móviles se actualizan mucho y muchas veces para dar la impresión de movimiento, si una app no cambia durante un tiempo los usuarios dejan de confiar en ella y se van con la competencia.

 

Muchas veces las actualizaciones de app's solo son de interfaz gráfica, que le ponen un botón mejorado, colores diferentes, incluso con solo cambiar el icono de la aplicación ya se genera una nueva descarga, pero eso es lo que a los usuarios "les gusta" de las aplicaciones hoy en día.

 

Y esto asumo que obedece al avance de la tecnología, antes era todo un lío porque se tenía que enviar "20 disquettes" para actualizar un programa, después un CD, hasta hace poco USB's por eso es que las actualizaciones eran mas espaciadas, ahora hay actualizaciones casi a diario.

 

Saludos


  • 0




IP.Board spam blocked by CleanTalk.