2010-06-29 9 views
6

He estado escribiendo software durante varias décadas y actualmente todo es web.
Antes de la web teníamos aplicaciones de Client Server que básicamente eran aplicaciones de cliente grueso que hablaban directamente a la base de datos. Tenían algunas desventajas, como la implementación era engorrosa. No se escamó porque DB manejó todo el tráfico. Por supuesto, en aquel entonces la distribución de aplicaciones se limitaba a estar en una computadora de escritorio en una red corporativa. Los beneficios de estas aplicaciones fueron que tenían menos capas y se desarrollaron rápidamente.¿Alguien todavía usa Client Server Architecture

Hay momentos en que los requisitos requieren una aplicación detrás de un firewall con una base de datos dedicada y una cantidad relativamente pequeña de clientes. Sugiero (a veces en StackOverflow) la vieja arquitectura de tipo Cliente/Servidor y todos me miran como si tuviera 3 patas y 6 brazos.

Con tecnologías modernas que permiten despliegues automáticos de aplicaciones y las herramientas que tenemos hoy en día. ¿Hay alguna razón por la cual esta tecnología no sea viable? ¿Es que la nueva generación de desarrolladores solo sabe cosas de la web?

+1

¿Qué, nunca escuché de las aplicaciones de Access? – Earlz

+1

¡Oye, chicos! ¡Sal de mi césped! – Stephen

+0

En estos días Me ahogo cada vez que alguien dice que los navegadores son clientes ligeros ... que no se asoman en la lista de complementos en mi FF ... –

Respuesta

6

Estoy seguro de que los clientes gruesos todavía se están desarrollando, incluso hoy en día.

Una vez dicho esto, la elección de una arquitectura basada en la web no se trata de la "nueva generación de desarrolladores", sólo saber cosas web, usted consigue un montón de ventajas si se puede hacer que su aplicación basada en web:

  1. La implementación es completamente simple. Incluso con cosas como ClickOnce, actualizaciones automáticas, etc., nada mejor que simplemente refrescar la página para obtener la última versión
  2. Puede usar algo como Silverlight para obtener el 99% de los beneficios de una aplicación de escritorio (en términos de la capacidad de ejecutar código en el cliente)
  3. Las aplicaciones web pueden estar disponibles remotamente mucho más fácilmente que las aplicaciones de escritorio (muchas empresas tienen trabajadores remotos en estos días, configurar una VPN es un dolor si todo lo que quiere hacer es acceder a la nómina (o lo que sea))

Pero a fin de cuentas, se trata de la herramienta adecuada para el trabajo. Las aplicaciones web no ayudan cuando quieres escribir complementos para Office (Word, Outlook, etc.), no ayudan si tienes que controlar el hardware personalizado (terminales POS, etc., aunque podrías escribir eso en el servidor en algunos casos ...), y probablemente también algunos casos más.

7

puedo pensar en por lo menos dos grandes mercados-ish en cliente-servidor sigue siendo un gran:

  • juegos en línea y mundos virtuales, como el campo de batalla o Second Life. Por lo general, necesita un cliente grueso además de una conexión a un servidor compartido.
  • Software científico por encargo. El software complejo, técnico o científico, especialmente si necesita una interfaz gráfica de usuario interactiva que manipula directamente, también se escribe a veces de esta manera.
1

Tenemos algunas aplicaciones de Flex que se comunican con servicios web basados ​​en XML que están muy cerca de las aplicaciones de Client Server de la vieja escuela. Pero en lugar de usar SQL, hablan un lenguaje XML personalizado y rinden respuestas SOAP.

+2

Luego necesita programar, mantener y administrar un nivel intermedio completo. XML es engorroso. Es una herramienta para muchas aplicaciones, pero estoy tratando de convencer a la gente de que nos hemos alejado de la simplicidad, donde a veces una solución más simple es aún mejor. También escribo aplicaciones GWT, así como aplicaciones web, así que entiendo la mecánica. –

1

Actualmente desarrollamos e implementamos numerosas aplicaciones cliente/servidor anualmente. El desarrollo es simple y automatizado. No estamos limitados a las tecnologías de bases de datos que podemos implementar.Las implementaciones cliente/servidor son más rápidas para cálculos, actualizaciones de formularios e informes. Las aplicaciones basadas en Web/Cloud responden menos que una aplicación que se ejecuta en una estación cliente (cliente grueso).

Esto es debido a la distribución de la carga de la CPU. Mientras que una aplicación del lado del servidor requiere que el servidor realice todos los cálculos, el lado del cliente puede ejecutar esto en la máquina local. A medida que un sistema se vuelve más complejo, aumentan los momentos en los que un usuario debe esperar para obtener resultados. Estos momentos de tiempo de los empleados son más caros ya que involucran a más empleados remunerados. Estos momentos se suman dentro de una organización como un gran número de "horas hombre" durante un año.

Los problemas con las actualizaciones se resuelven dentro de nuestro conjunto de herramientas de desarrollo. Al igual que cuando puede abrir su navegador favorito, nota que la versión que está utilizando no es la más reciente, insertamos el mismo proceso en nuestras aplicaciones cliente/servidor. De hecho, no les damos la opción de actualizar. Dado que las actualizaciones pueden, muchas veces, requerir cambios en la base de datos, forzamos la actualización antes de que el usuario pueda ejecutar el software.

Para mejorar la visibilidad de la información contenida en nuestros sistemas cliente/servidor personalizados, ofrecemos sitios web personalizados que tienen aplicaciones específicas como envío de campo o integración de foro de soporte al cliente en las aplicaciones cliente/servidor de escritorio. Desde mi perspectiva, veo una integración completa del servidor del cliente y las aplicaciones web receptivas que ocuparán una posición mejor en los años venideros.