57 votos

Del lado del cliente de la lógica O lógica del lado del Servidor?

He hecho algunos proyectos basados en web, y la mayoría de las dificultades que me he encontrado con el (preguntas, confusiones) podría ser resuelto con la ayuda. Pero todavía tengo una pregunta importante, incluso después de preguntar a algunos desarrolladores experimentados: Cuando la funcionalidad se puede implementar con tanto código del lado del servidor y del lado del cliente de scripts (JavaScript), que uno debe ser preferido?

Un ejemplo sencillo:

Para renderizar una página html dinámico, puedo formato de la página de código del lado del servidor (PHP, python) y el uso de Ajax para recuperar el formato de la página y hacerla directamente (más lógica en el lado del servidor, y menos en el lado del cliente).

También puedo usar Ajax para recuperar los datos (no tiene el formato JSON) y el uso de secuencias de comandos de cliente para dar formato a la página y hacerla con más de procesamiento (el servidor recibe los datos de un DB o de otra fuente, y se la devuelve al cliente con JSON o XML. Más lógica en el lado del cliente y menos en el servidor).

Entonces, ¿cómo puedo decidir cuál es el mejor? Que uno ofrece un mejor rendimiento? Por qué? Cuál es el más amigable para el usuario?

Me pregunto, con navegadores,' JS motores de la evolución, JS pueden ser interpretados en menos tiempo. Así que debo yo prefiero secuencias de comandos de cliente?

También me pregunto, con el hardware de la evolución, el rendimiento del servidor que va a crecer y el costo se reducirá, por lo que debe prefiero scripting del lado del servidor?

EDITAR:

Con las respuestas, quiero dar un breve resumen.

Pros del lado del cliente:

  1. mejor experiencia de usuario
  2. ahorrar ancho de banda de red (disminución de costos)
  3. escalabilidad (con el auge de la PVs, el crecimiento no va a crecer tanto como la parte lógica del servidor)

Pros de lado del servidor:

  1. los problemas de seguridad
  2. mejorar la disponibilidad y accesibilidad (dispositivo móvil, navegadores antiguos, SEO)
  3. ampliar fácilmente(se puede añadir más servidores, pero no podemos hacer que el navegador más rápido)

Parece que necesitamos para equilibrar estos dos enfoques cuando se enfrenta a una situación específica. Pero, ¿cómo? ¿Cuál es la mejor práctica?

De la OMI, voy a utilizar en el cliente la lógica excepción de las siguientes condiciones:

  1. de seguridad crítica
  2. grupos especiales (JavaScript deshabilitado, dispositivos móviles, etc)

23voto

Eric J. Puntos 73338

En muchos casos, me temo que la mejor respuesta es tanto.

Como Ricebowl declaró, nunca confiar en el cliente. Sin embargo, creo que es casi siempre un problema si usted confía en el cliente. Si su aplicación de la pena de escritura, es que vale la pena proteger correctamente. Si alguien puede romper mediante la escritura de su propio cliente y de la transferencia de datos no espera, eso es una mala cosa. Por esa razón, usted necesita para validar en el servidor.

Desafortunadamente, si usted validar todo en el servidor, que a menudo deja al usuario con una experiencia de usuario pobre. Puede llenar un formulario sólo para encontrar que un número de cosas que entró son incorrectos. Esto puede haber trabajado para "Internet 1.0", pero las expectativas de la gente son más altos en la Internet de hoy en día.

Potencialmente, esto te deja escribir un poco de código redundante, y el mantenimiento de ésta en dos o más lugares (algunas de las definiciones tales como la longitud máxima también deben ser mantenidos en el nivel de datos). Razonablemente aplicaciones grandes, que tienden a resolver este problema mediante la generación de código. Personalmente yo uso una herramienta de modelado con UML (Sparx del Sistema de Enterprise Architect) para el modelo de las "reglas de entrada" del sistema, a continuación, hacer uso de las clases parciales (normalmente estoy trabajando .NET) para generar el código de validación de la lógica. Usted puede lograr una cosa similar mediante la codificación de las reglas en formato XML y la obtención de un número de comprobaciones de que el archivo XML de entrada (longitud, máscara de entrada, etc.) en ambos el cliente y el servidor de nivel.

Probablemente no es lo que quería escuchar, pero si quieres hacerlo bien, usted necesita para hacer cumplir las reglas en ambos niveles.

14voto

David Thomas Puntos 111253

Tiendo a preferir lógica del lado del servidor. Mis razones son muy simples:

  1. Yo no confio en el cliente; esto puede o no ser un verdadero problema, pero es habitual
  2. En el lado del servidor se reduce el volumen de cada transacción (aunque aumenta el número de transacciones)
  3. En el lado del servidor significa que puedo estar bastante seguro de lo que la lógica está teniendo lugar (no tiene que preocuparse por el motor de Javascript disponibles para el navegador del cliente)

Probablemente hay más-y mejor - razones, pero estas son las que están en la parte superior de mi mente ahora mismo. Si pienso en más voy a añadir, o votar a aquellos que vienen con ellos antes que yo.


Editado, valya comentarios de que el uso de lógica de cliente (usando Ajax/JSON) permite (más fácil) la creación de un API. Esto bien puede ser cierto, pero yo sólo la mitad-de acuerdo (que es la razón por la que no me he up-votaron a favor de que la respuesta todavía).

Mi noción de la lógica del lado del servidor es aquel que recupera los datos y los organiza; si tengo este derecho, la lógica es el 'controller' (C en MVC). Y esto se pasa a continuación a la vista.' Yo tiendo a usar el controlador para obtener los datos y, a continuación, el 'punto de vista' trata con la presentación ante el usuario/cliente. Así que no veo que el cliente/servidor distinciones son necesariamente relevantes para el argumento de la creación de una API, básicamente: caballos de carreras. :)

...también, como un aficionado, he de reconocer que yo pueda tener un poco torcido el uso de MVC, así que estoy dispuesto a ser corregido en ese punto. Pero todavía guardo la presentación separada de la lógica. Y que la separación es el punto más tan lejos como las Api de ir.

5voto

James Jones Puntos 3291

Yo por lo general implementar tanto como razonable del lado del cliente. Las únicas excepciones que se me haría ir en el lado del servidor sería resolver el siguiente:

Problemas de confianza.

Cualquier persona es capaz de depuración de JavaScript y la lectura de la contraseña, etc. Obviedad aquí.

Problemas de rendimiento

JavaScript son los motores de la evolución de rápido, así que esto se está convirtiendo en un problema menor, pero todavía estamos en una IE-dominaban el mundo, así que las cosas se ralentizan cuando se trabaja con grandes conjuntos de datos.

Problemas de lenguaje

JavaScript es débilmente tipado lenguaje y hace un montón de suposiciones de su código. Esto puede causar que emplean a spooky soluciones en orden a conseguir que las cosas funcionen de la manera en que debe en ciertos navegadores. Evitar este tipo de cosa como de la peste.


Por tu pregunta, suena como que usted está simplemente tratando de cargar los valores en un formulario. De no mediar alguna de las cuestiones anteriores, usted tiene 3 opciones:

Puros del lado del cliente

La desventaja es que los usuarios, el tiempo de carga sería el doble (una carga para el formulario en blanco, otra carga de los datos). Sin embargo, las actualizaciones posteriores de la forma no sería necesario una actualización de la página. Los usuarios como este si que habrá un montón de obtención de datos desde el servidor de la carga en el mismo formulario.

Puro en el lado del servidor

La ventaja es que su página se carga con los datos. Sin embargo, las actualizaciones posteriores de los datos requeriría se actualiza para todos/porciones significativas de la página.

Cliente-servidor híbrido

Usted podría tener lo mejor de ambos mundos, sin embargo, usted necesita para crear datos de dos de los puntos de extracción, la causa de su código para engordar un poco.

Hay trade-offs con cada opción, así que usted tendrá que sopesar y decidir que uno se brinda el mayor beneficio.

3voto

DVK Puntos 63282

Una consideración no he escuchado fue mencionado ancho de banda de red. Para dar un ejemplo concreto, una aplicación que estaba involucrado, fue hecho en el lado del servidor y resultó en 200Mb página web que se envía al cliente (era imposible hacer menos sin grandes grandes re-diseño de un montón de aplicaciones); resultando en 2-5 minutos tiempo de carga de página.

Cuando nos re-implementado mediante el envío de JSON-codificado de datos desde el servidor y locales JS generar la página, el principal beneficio fue que los datos enviados reducido a 20Mb, lo que resulta en:

  • Respuesta HTTP tamaño: 200Mb+ => 20 mb+ (con el correspondiente ahorro de ancho de banda!)

  • Tiempo de carga de la página: 2-5 minutos => 20 segundos (10 a 15 de los cuales son tomados por DB consulta que se ha optimizado para el infierno una más).

  • Es decir el proceso tamaño: 200MB+ => 80 MB+

La mente, los 2 últimos puntos fueron principalmente debido al hecho de que el lado del servidor tenido que usar la mierda de tablas dentro de tablas árbol de implementación, mientras que va para el lado cliente nos permitió rediseñar la capa de la vista uso mucho más ligero de la página. Pero mi punto principal fue la red de ahorro de ancho de banda.

2voto

Jerry Puntos 766

He construido un Descanso de la aplicación web donde todos los CRUD funcionalidades están disponibles en la ausencia de JavaScript, en otras palabras, todos AJAX efectos son estrictamente progresivo de mejoras.

Yo creo que con la suficiente dedicación, la mayoría de las aplicaciones web pueden ser diseñados de esta manera, deteriorando muchos de la lógica de servidor vs cliente lógica de "diferencias", tales como la seguridad, la capacidad de expansión, planteadas en su pregunta, porque en ambos casos, la solicitud se dirige a la misma controladora, de las cuales la lógica de negocio, es todo lo mismo hasta la última milla, donde JSON/XML, en lugar de toda la página HTML, se devuelve para las XHR.

Sólo en pocos casos donde la AJAXified aplicación es inmensamente más avanzado que el de su estática contraparte, GMail siendo el mejor ejemplo que viene a mi mente, entonces uno necesita crear dos versiones y separarlos completamente (Felicitaciones a Google!).

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X