PDF de programación - compartiMOSS 15 - Revista especializada en Tecnologías SharePoint

COMPARTIMOSS COMPARTIMOSS 03 Editorial

En esta nueva etapa de CompartiMOSS, iniciada con el número
14, y con la nueva versión de SharePoint completamente
asentada en el mercado y disponible de forma global desde
el pasado mes de enero, les presentamos la edición 15 de la
revista, cargada de artículos de calidad en los que nuestros
autores y colaboradores han realizado un excelente trabajo
transmitiendo sus conocimientos y su experiencia en los
distintos temas tratados.

El tirón y popularidad de la revista sigue creciendo gracias a
una gran base de autores qué número a número aumenta, el
trabajo coordinado de la dirección y la continua evolución de
nuestra web (www.compartimoss.com) realizada por nuestros
compañeros Alberto Díaz y Santiago Porras, sin olvidar el
soporte de nuestros patrocinadores, por supuesto. Como
siempre, en este nuevo número se ha intentado combinar

artículos de carácter técnico (sobre todo en torno a SharePoint
2013) con artículos de negocio, de buenas prácticas y de casos
de la vida real que exponen las posibilidades y alcance qué
tiene una de las plataformas estrella de Microsoft.

Esperamos que disfruten de este número y que los artículos
contenidos en el mismo sean de su agrado e interés.

Abril, 2013

JUAN CARLOS GONZÁLEZ
[email protected]
GUSTAVO VÉLEZ
[email protected]
FABIÁN IMAZ
[email protected]

03

COMPARTIMOSS 04

ASP.NET MVC para
SharePointeros (I)

Resumen
En este artículo veremos las bases de la programación de
aplicaciones web con ASP.NET MVC, con un ejemplo sencillo
de conexión a SharePoint.

Artículo
Los programadores SharePoint estamos tan acostumbrados
a programar con ASP.NET Web Forms que no nos solemos
preocupar por aprender otras tecnologías de programación
ya que no se pueden aplicar directamente a SharePoint. Sin
embargo, desde la versión 2010 de SharePoint, con el modelo
de objetos de cliente (CSOM) podemos acceder a SharePoint
desde cualquier aplicación .NET,
incluyendo también el
framework ASP.NET MVC, que vamos a introducir en este
artículo.

Lo básico de MVC
En el mundo de ASP.NET Web Forms la base de todo es la página
(instancia de clase Page). La página está mapeada físicamente
a un fichero con extensión ASPX y dispara una serie de eventos
(Init, Load, PreRender, Render etc) según vamos progresando
de la petición HTTP a la respuesta HTML al cliente. Podemos
decir que en cierto modo Web Forms implementa el patrón
“Page Controller” .

En el mundo MVC esto ya no es así. La responsabilidad de
servir la respuesta a una petición está dividida entre tres
componentes que dan nombre al patrón de diseño MVC:
modelo, vista y controlador.

El modelo son nuestras clases de negocio junto con su lógica
de negocio. La vista es la renderización HTML de la respuesta al
cliente mientras que el controlador es la lógica de la aplicación
web que procesa el modelo y actualiza la vista. En el mundo
Web Forms, la página hacía de vista y de controlador a la vez.
Ahora estas dos cosas están bien separadas.

Las peticiones, rutas, acciones y otras
cosas de nombre extraño
Vamos a ver como procesa ASP.NET MVC una petición y lo
vamos a comparar con Web Forms para ver las diferencias.
Supongamos que queremos ver un producto cuyo ID es 5.
En Web Forms haríamos una página DisplayProduct.aspx y
recogeríamos un parámetro desde Request.QueryString con el

nombre ID. Es decir, la URL de la petición sería DisplayProduct.
aspx?ID=5.

En MVC, la URL de la petición no apuntará a ningún fichero
físico sino que nos indicara el controlador (de todos los
controladores que hay), la acción (dentro de ese controlador)
y posiblemente algún parámetro de esa acción. Una URL
probable sería /Products/Display/5, indicando el controlador
Products, acción Display con el parámetro 5.

Seguro que ahora os estáis preguntando como sabe MVC a
que controlador tiene que enviar la petición y que vista se
tiene que mostrar. Resulta que MVC por defecto interpreta
la URL en el formato “controlador/acción/parámetro” y de
esta manera la URL /Products/Display/5 equivale al invocar
ProductsController.Display(5). ¿Y la vista? MVC la busca dentro
de la subcarpeta Products de las vistas y buscará la que tiene
como nombre Display. Como podéis ver, se favorece el uso
de convenciones comunes de nombres para ahorrar código
innecesario de infraestructura.

Imagen 1.- El esquema de funcionamiento de una petición MVC.

Una acción en el controlador será un método que devuelve

04

COMPARTIMOSS un resultado, que casi siempre será una vista. La acción
puede recibir parámetros (sencillos o incluso complejos) y
puede pasarle los parámetros a la vista. Lo más habitual es
que la acción realice alguna comprobación de validez de los
parámetros y que use otras clases y servicios para llamar a
la lógica puramente de negocio. Se suele utilizar inyección
de dependencias para desacoplar aún más los controladores
(lógica de la capa web de presentación) de la funcionalidad de
negocio (capa de dominio o de negocio).

Las vistas en ASP.NET MVC se pueden hacer en Web Forms
(ficheros ASPX) o con la nueva tecnología llamada Razor. Se
recomienda Razor por ser mucho más sencillo y rápido. Razor
tiene una sintaxis más minimalista y cuesta un cierto tiempo
acostumbrarse a él. En contraprestación, se corresponde más
al HTML final.

List<Product> result = new
List<Product>();

result.Add(new Product() { Name = "ACME
Gadget", ProductId = 1 });
result.Add(new Product() { Name = "XYZ
Widget", ProductId = 2 });
result.Add( new Product() { Name =
"Product ABC", ProductId = 4 });
result.Add( new Product() { Name = "Foo
DEF", ProductId = 5 });

return result;
}
}

Abrimos Visual Studio y creamos una aplicación web MVC 3
con la plantilla “Empty Application”. Dejamos las opciones por
defecto y nos encontramos con la siguiente estructura de un
proyecto MVC.

@model MvcHelloWorld.Models.Product
@{
ViewBag.Title = "Display";
}
<h2>Display</h2>
<p>@Model.Name <em>(@Model.ProductId)</em></p>

public class ProductsController : Controller
{
public ActionResult Index()
{
return View();
}
}

Fijaos que Razor usa el prefijo @ para introducir su marcado de
servidor. En este ejemplo le estamos diciendo a la vista que va
a usar un tipo de datos como modelo (la clase MvcHelloWorld.
Models.Product) y luego en el contenido de la página se usan
las propiedades de ese modelo mediante la sintaxis @Model.

public class DBHelper
{
public static Product GetProduct(int
Hello, world en MVC
productId)
{
Para acabar de sentar el concepto de una aplicación MVC,
@model MvcHelloWorld.Models.Product
var product = GetProducts().Where(x =>
vamos a hacer un ejemplo sencillo: una aplicación que
@{
x.ProductId == productId).FirstOrDefault();
ViewBag.Title = "Display";
permite ver la lista de productos y el detalle del producto. Para
return product;
@model MvcHelloWorld.Models.Product
}
}
simplificar esta primera toma de contacto con MVC, vamos
@{
<h2>Display</h2>
a usar la lista de productos fija implementada en la clase
ViewBag.Title = "Display";
<p>@Model.Name <em>(@Model.ProductId)</em></p>
public static IEnumerable<Product>
DBHelper. Más adelante usaremos la API de SharePoint para
}
GetProducts()
<h2>Display</h2>
obtener la lista desde un sitio de SharePoint.
{
<p>@Model.Name <em>(@Model.ProductId)</em></p>
public class DBHelper
List<Product> result = new
List<Product>();

result.Add(new Product() { Name = "ACME
Gadget", ProductId = 1 });
public class DBHelper
result.Add(new Product() { Name = "XYZ
{
Widget", ProductId = 2 });
public static Product GetProduct(int
result.Add( new Product() { Name =
public class DBHelper
productId)
"Product ABC", ProductId = 4 });
{
{
result.Add( new Product() { Name = "Foo
public static Product GetProduct(int
var product = GetProducts().Where(x =>
DEF", ProductId = 5 });
productId)
x.ProductId == productId).FirstOrDefault();
{
return product;
return result;
var product = GetProducts().Where(x =>
}
}
x.ProductId == productId).FirstOrDefault();
}
return product;
public static IEnumerable<Product>
}
GetProducts()
{
public static IEnumerable<Product>
List<Product> result = new
GetProducts()
List<Product>();
{
List<Product> result = new
result.Add(new Product() { Name = "ACME
List<Product>();
Gadget", ProductId = 1 });
result.Add(new Product() { Name = "XYZ
public class ProductsController : Controller
result.Add(new Product() { Name = "ACME
Widget", ProductId = 2 });
{
Gadget", ProductId = 1 });
result.Add( new Product() { Name =
public ActionResult Index()
result.Add(new Product() { Name = "XYZ
"Product ABC", ProductId = 4 });
{
Widget", ProductId = 2 });
result.Add( new Product() { Name = "Foo
return View();

Imagen 2.- Estructura de un proyecto web MVC.

“... podemos acceder a SharePoint desde
cualquier aplicación .NET, incluyendo
también el framework ASP.NET MVC.”

LAS CARPETAS MÁS IMPORTANTES SON:
• Content: contenido estático (HTML, ficheros auxiliares,
documentos, etc).
• Controllers: aquí irán nuestros controladores.
• Models: las clases que componen el modelo de la
aplicación irán aquí. En nuestro caso allí tendremos la clase
Product y la clase DBHelper que simula una llamada a base de
datos.
• Scripts: los ficheros de JavaScript para nuestra aplicación.
De serie ya tenemos jQuery y Modernizr.
• Views: aq