SharePoint 2013: Patrones de diseño de aplicaciones (I)!

Cuando vamos a implementar aplicaciones para SharePoint 2013 y SharePoint Online en Office 365, tenemos que tener en mente tanto el objetivo de la aplicación como los posibles patrones de diseño que tenemos disponibles y que se corresponden con los tres tipos generales de aplicaciones que se pueden crear: Hospedadas por SharePoint, Autohospedadas y Hospedadas por un proveedor. Si nos centramos en la cuestión de patrones de diseño de aplicaciones, podemos diferenciar al menos tres:

  • Patrón “Client-Side”, caracterizado por el uso de tecnologías como HTML 5, CSS y JavaScript. En el caso de JavaScript, estaríamos hablando de librerías como ASP.NET AJAX y sobre todo jQuery.
  • Patrón “Server-Side”, en este caso las aplicaciones “viven” fuera de SharePoint ya sea en infraestructura propia (Provider-Hosted) o no (Provider-Hosted o Autohosted). A nivel de tecnologías, podemos hablar de mundo Microsoft o no de manera que tendremos un espectro amplio de posibilidades para crear aplicaciones: .NET, LAMP, JAVA, PHP, etc.
  • Patrón Híbrio, como su nombre indica es un mix de los dos patrones anteriores.

Una vez explicados los tres tipos de patrones que tenemos para crear aplicaciones, vamos a tratar de entrar en el detalle de los mismos:

Patrón “Client-Side”

Tiene las siguientes características:

  • Permite crear aplicaciones con páginas que tenga code behind, pero teniendo en cuenta que a nivel de tecnologías qué se pueden usar estamos restringidos a HTML 5, CSS y JavaScript. Por lo tanto, qué nadie piense en qué code beind es ASP.NET de lado de servidor, lo es pero en el lado del cliente.
  • Crear aplicaciones de acuerdo a este patrón implica aprender técnicas de programación de lado de cliente y sobre todo librerías JavaScript como ASP.NET AJAX, jQuery, jsRender o SignalR.
  • Además de poder crear páginas con código en cliente, en las aplicaciones con este patrón podremos incluir elementos como:
    • Columnas de sitio.
    • Tipos de contenido.
    • Definiciones de lista.
    • Instancias de lista.
    • Páginas de sitio.
    • Páginas de WebParts.
    • WebParts en sí misma (aunque sólo de tipo Client WebPart).
    • Páginas maestras.

image

  • Finalmente, os dejo la “foto” de este patrón.

image

Patrón “Server-Side”

El patrón “Server-Side” tiene las siguientes características:

  • Podemos escribir código en el lado del servidor, ya sea .NET o no. El problema de este patrón es qué es necesaria una infraestructura ajena a la granja de SharePoint dónde podamos desplegar las aplicaciones creadas. Las posibilidades son dos:
    • Disponer de un entorno propio en el qué tengamos uno o varios servidores web en los que se ejecuta nuestra aplicación con código en el lado de servidor.
    • Hacer uso de entornos de terceros como puede ser Azure en los que únicamente despleguemos nuestras aplicaciones y paguemos por uso. De echo, en el caso de aplicaciones de tipo Autohosted para SharePoint Online es esta la idea: creamos aplicaciones ASP.NET clásicas y las publicamos en Azure para luego ser agregadas en nuestros sitios de SharePoint Online en Office 365.
  • Desde el punto de vista de tecnologías, tenemos mucha flexibilidad ya que podemos usar .NET o no (LAMP, JAVA, PHP, etc) para crear nuestras aplicaciones:
    • Si nos decantamos por .NET, podremos elegir entre C# y VB.NET, además de la versión de .NET Framework que mejor se adapte a nuestros requerimientos. Por ejemplo, tendremos la opción de escoger la última versión de .NET Framework y no estar atados a seleccionar la versión de .NET Fx usada por SharePoint como sucede con versiones previas de SharePoint al crear artefactos que extiendan la plataforma.
  • Desde estas aplicaciones podremos realizar operaciones con informaciones/servicios de SharePoint si es necesario gracias a la API de cliente (sólo para aplicaciones en las qué se use .NET como tecnología de desarrollo) o bien la API de servicios REST (para cualquier tecnología).
  • Como en el caso de las aplicaciones qué siguen el patrón “Client-Side”, con este tipo de aplicaciones podremos desplegar los mismos artefactos propios de SharePoint vistos.
  • El esquema del patrón “Server-Side” es el siguiente:

image

Patrón híbrido

Finalmente, el patrón híbrido toma características de los otros dos patrones lo que le hace más flexible ya que:

  • Nos permite utilizar código en el lado del cliente y código en el lado del servidor.
  • Desde el punto de vista de diseño de la arquitectura de la aplicación, este resulta mucho más “limpio” y claro (opinión personal”) qué por ejemplo en el caso del patrón “Server-Side”.

image

 

Fuente: Material del training de desarrollo de Ignite de Microsoft disponible online para descarga.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

2 comentarios en “SharePoint 2013: Patrones de diseño de aplicaciones (I)!”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *