Middle Tier (un método alternativo para desarrollar en SharePoint) ~ SURPOINT

Guau! Cómo me gusta leer este tipo de artículos, bien desarrollados, muy polémicos y de los que nos hacen pensar! Hace un par de días, Marc D Anderson ha escrito un excelente white paper: The Middle Tier Manifesto- An Alternative Approach to Development with Microsoft SharePoint. Este artículo nos hace pensar acerca de las diferentes formas de desarrollar en SharePoint y nos explica porque no debemos asumir que escribir código en C# es la única forma válida de "desarrollar" en SharePoint.

Les propongo que lean el paper original (en inglés). Arriba está el link. En este artículo voy a hacer una libre interpretación, traducción y resumen, que espero disfruten :-)

Introducción

La premisa es que escribir código administrado en Visual Studio es más costoso en tiempo y esfuerzo y más propenso a los bugs. Como alternativa, tenemos la capa intermedia, que Marc nos presenta en este artículo. Dicho de otra manera, si usted piensa que las estimaciones de sus desarrolladores SharePoint (.Net) son prohibitivas, existe un método alternativo. The middle tier.

Qué es la middle tier?

Empecemos identificando las tres capas:

Capa 1) La interfaz de usuario y el Central Administrator
Capa 2) SharePoint Designer o mejor dicho: Data View Web Parts, Scripting (JavaScript & jQuery) y hojas de estilo en cascada (CSS)
Capa 3) Visual Studio. C# y el modelo de objetos de SharePoint, DLLs, GAC.

Qué es desarrollo? :-)

La definición no dice nada acerca de qué es el software. Es por ello que no sería correcto afirmar que si no es "desarrollo .Net", entonces no es desarrollo verdadero, verdad :-)?

Lo importante, respecto al desarrollo, es que necesitas disciplina y organización, habilidad para dividir un problema complejo en piezas manejables, detectar acciones repetibles y crear código. Pero no son las herramientas las que generan las buenas soluciones, sino la gente o dicho de otras manera: las buenas herramientas no son una excusa para pensar en forma equivocada...

Entonces, qué es un desarrollador SharePoint?

La definición más común (y tal vez la más errónea) es que se trata de "un desarrollador .Net que entiende el modelo de objetos de SharePoint".

... Pero que Microsoft haya creado SharePoint sobre la base de .Net no quiere decir que la única forma de desarrollar sobre SharePoint es usando las herramientas .Net.

Porque la capa intermedia es un método diferente?

Desarrollar en esta capa implica usar herramientas diferentes a las utilizadas en las otras dos capas.

Data View Web Parts:

Estos elementos web consumen XML y generan diferentes salidas usando XSL para definir el formato. Pueden trabajar con los siguientes tipos de orígenes de datos:

Listas y librerías
Conexiones a base de datos
Archivos XML
Server-side scripts
XML Web Services

Mucha gente se siente frustrada al trabajar con SharePoint Designer, porque intenta hacer todo a través de las pantallas de esta herramienta. Sin embargo las posibilidades aumentan cuando los cambios se efectúan directamente en el XSL (claro que esto no tiene vuelta atrás). La buena práctica es avanzar lo más lejos posible con las pantallas y luego introducirse en el XSL.

Scripting

Nos permite crear funcionalidad que se ejecute en la máquina del cliente. Existe funcionalidad en SharePoint 2007 construida en JavaScript.

Sin embargo las posibilidades se amplían enormemente con jQuery, ahora soportado por Microsoft. jQuery (I love jQuery) es una abstracción de JavaScript que nos permite hacer "cosas" más rápida y fácilmente. jQuery es JavaScript. Una vez que lo habilitamos contamos con innumerable cantidad de plugins alrededor del mundo disponibles para nuestra aplicación.
El código jQuery puede incluirse en una Content Editor Web Part, en una página, una plantilla de página o una página maestra. Eso dependerá de nuestras necesidades.

CSS

Por supuesto se puede usar en todas las capas, pero... en la intermedia se vuelve más importante. Muchos de los mejores trucos que usan CSS se ejecutan durante la "vida" de la página en el browser.

Flujos de trabajo basados en SharePoint Designer

Los flujos de trabajo out of the box son demasiados simples. Aquellos creados en SharePoint Designer nos permiten implementar procesos de negocio más complejos. En muchos casos, lo que podremos hacer con SharePoint Designer será más que adecuado. Por supuesto que Visual Studio nos provee una herramienta robusta para trabajar con flujos de trabajo, pero SharePoint Designer es una buena alternativa.

ah!

El código de las herramientas de la capa intermedia es interpretado en tiempo de ejecución, no existe código compilado en el servidor. Esto hace que los desarrollos en la capa intermedia, difícilmente alteren el comportamiento del servidor. Los mayores problemas con las granjas de Servidores SharePoint ocurren con componentes creados por desarrolladores (incluso buenos desarrolladores) e instalados en el servidor.

Las herramientas de capa media, no puedan causar grandes problemas en el servidor. Esto es un tema de diseño. Microsoft asegura que la capa de scripting no puede impactar los archivos del servidor.
Muchas veces se dice que las soluciones de capa intermedia no son performantes, porque se almacenan en la base de datos. Esto no es cierto. Por supuesto es posible desarrollar código ineficiente en la capa intermedia, pero es más común hacerlo en la tercera capa. Como se dijo anteriormente, los buenos desarrolladores escriben buen código, independientemente de la herramienta.

Beneficios de la capa intermedia

Skills más fáciles de encontrar: XML, XSL, CSS, JavaScript, jQuery, Web Services.
Herramientas de menor costo: SharePoint Designer es gratuito.
Ciclos de prueba reducidos: al no requerir instalación de componentes en el servidor.
Adaptabilidad en ambientes corporativos: como a muchos les habrá pasado, instalar componentes de servidor puede ser una tarea prohibida en las corporaciones. En otros casos está permitido, pero requiere pasar por procedimientos de aprobación, que pueden ser aceptables en la instalación de una primera versión, pero no tanto en una actualización o corrección de un defecto.
Servidores más estables: explicado anteriormente.
Los backups capturan la solución completa: porque todo el código se almacena en la base de datos.

Desventajas

SharePoint Designer: puede ser una herramienta "bloqueada" por el departamento de sistemas.
Despliegue: aquí tenemos problemas, Microsoft no ha invertido mucho en pensar cómo manejar el despliegue en la capa intermedia.
Repetitividad: es más complicado, aunque no imposible, trabajar con soluciones reusables. Sin embargo existen técnicas para mitigar este problema.
Performance: hay muchas escuelas de pensamiento alrededor de este tema. En algunos casos las soluciones de capa intermedia son menos performantes que las de código administrado. Pero esto no siempre es así. Es importante que tomemos las decisiones basándonos en datos reales y no en especulaciones.

Buenas prácticas en la capa intermedia

Código modular: aplican los mismos conceptos de siempre de programación. Por ejemplo, es bueno crear librerías de scrips.
Código reusable: puede ser instalado en una librería de documentos.

Concluyendo

Como se estarán imaginando, no hay balas de plata. Las siguientes preguntas pueden ayudarnos a decidir:

De qué skills dispongo en el equipo?
De qué nivel de acceso al servidor disponemos? Si la respuesta es nada o poco, entonces la capa intermedia es la solución
Qué tan frecuente debo actualizar la solución?
Que requerimientos de seguridad tengo?
Que nivel de volumen es esperado para las listas?
Cuándo quiero o puedo gastar?
Quick ROI?

SURPOINT

viernes, 16 de abril de 2010