Herramientas de usuario

Herramientas del sitio


code:best-practices

¡Esta es una revisión vieja del documento!


Codificando

Conceptos que hay que tener en cuenta a la hora de programar.

Programación declarativa

El código imperativo describe cómo se hace algo, mientras el declarativo describe qué se está haciendo.
La programación declarativa expresa la lógica sin describir un flujo (if, bucles…).

El código siguiente es imperativo:

using System;
class Example
{
    static void Main()
    {
        Int32 sum = 0;
        for (Int32 i = 0; i < 100; i++)
        {
            if (i % 2 == 0)
            {
                sum += i;
            }
        }
        Console.WriteLine(sum);
    }
}

Su equivalente declarativo sería:

using System;
using System.Linq;
 
class Example
{
    static void Main()
    {
        Int32 sum = Enumerable.Range(0, 99)
                      .Where(i => i % 2 == 0)
                      .Sum();
        Console.WriteLine(sum);
    }
}

O con un grado declarativo mayor:

using System;
using System.Linq;
 
class Example
{
    static void Main()
    {
        Int32 sum = Enumerable.Range(0, 99)
                      .Where(isEven)
                      .Sum();
        Console.WriteLine(sum);
    }
    static Boolean isEven(Int32 number)
    {
        return number % 2 == 0;
    }
}

Web Services

REST Web Services

La arquitectura REST (Representational State Transfer) es un estilo de distribución de datos mediante la web aprovechando el protocolo HTTP (métodos, URIs, Media Types, codigos de respuesta y petición…). Básicamente consiste en clientes que realizan peticiones a servidores, estos las procesan y retornan la respuesta adecuada.
Tanto las peticiones como las respuestas intentan “representar recursos” (de ahí su nombre), entendiendo un recurso como “contenido” que puede ser accedido a partir de una dirección.
En cualquier momento la aplicación cliente entrará en una transición de “estados de aplicación” (transición entre las distintas acciones que realiza una aplicación), se dice que si la aplicación entra en un estado “de descanso” (at rest) el usuario podrá interactuar con ella pero esta no cargará ni consumirá datos. La aplicación cliente enviará peticiones cuando esté preparada para una nueva transición.
Un servicio REST asegura rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad portabilidad y confiabilidad.

Servicios RESTful

Las reglas a seguir en una arquitectura de estilo REST son las siguientes, si se siguen todas (excepto 'código on demand') el servicio podrá ser denominado RESTful:

  1. Cliente - Servidor: La interface de cliente está separada del servidor, esto significa que no pueden acceder directamente a los datos si no es a partir del mismo servidor. Por otra parte tanto el cliente como el servidor son independientes y han de ser desarrollados por separado.
  2. Sin estados: Las peticiones del cliente se harán de una en una y no por partes, cada una de estas contendrán toda la información necesaria para realizarla. Las peticiones se harán a partir de una URL.
  3. Cacheable: Los clientes han de ser capaz de guardar en caché las respuestas del servidor.
  4. Sistema por capas: Pueden existir servidores intermedios que mejoren la escalabilidad del sistema permitiendo el balanceo de carga y compartir cachés.
  5. Código on demand (opcional): El servidor puede ser capaz de transferir código al cliente (como por ejemplo JavaScript).
  6. Interface uniforme: Esto simplifica y desacopla la arquitectura, lo que permite a cada parte evolucionar independientemente. En una interface uniforme…
    • Los recursos han de estar identificados en las peticiones. Esto significa que el servidor enviará los datos correctamente identificados en el formato que sea (HTML, XML, JSON…) y estos pueden ser una porción de la DB.
    • Los recursos pueden ser manipulados. Esto significa que si el cliente tiene suficiente información del recurso y a la vez tiene suficientes permisos podrá realizar sobre este acciones de modificación, de borrado…
    • Mensajes autodescriptivos. Cada mensaje ha de incluir suficiente información para que este pueda ser procesado.
    • Los recursos han de ser reconocidos por métodos de hypermedia (como por ejemplo URIs).
code/best-practices.1278354770.txt.gz · Última modificación: 2020/05/09 09:24 (editor externo)