Cómo crear tu primerMVC WebPart en Sharepoint 2010

Ing. Randall Barnett Villalobos, MciDBA / DeveloperInstituto Costarricense de Electricidad

Preliminares

Agile

Scrum XP

Qué es MVC?Sección 1 de 5

Es confuso el MVC?En dos ocasiones me preguntaron - "Disculpe, Sr. Babbage, si pongo números incorrectos en la máquina, ¿van a salir las respuestas correctas?"... No puedo terminar de comprender el tipo de confusión de ideas que podrían provocar esta pregunta".

Qué es el MVC?Modelo Vista Controlador (MVC) es un patrón o modelo de abstracción de desarrollo de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.

ModeloEsta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.

VistaEste presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.

ControladorEste responde a eventos, usualmente acciones del usuario e invoca peticiones al modelo y probablemente, a la vista.

ImplementacionesAunque se pueden encontrar diferentes implementaciones de MVC, los flujos más comunes son generalmente los siguientes:1. El Modelo Pasivo2. El Modelo Activo

El Modelo PasivoEste es empleado cuando un Controlador manipula el Modelo exclusivamente. El Controlador modifica al Modelo y luego notifica a la Vista que dicho Modelo ha sido cambiado.

El Modelo ActivoEsta variante es usada cuando el Modelo cambia de estado sin la intervención del Controlador.

Arquitectura del MVC

.NET Framework

ASP .NET Core

ASP .NETWebforms

ASP .NETMVC

Toolkits para GUIdel ASP.NET Runtime

Servicios del core de ASP.NETcomo el caching, configuartion, etc.

El Runtime normal de .NET.

Vista

Controlador

Modelo(s)

Data Accessor(s)

Base(s) de Datos

Objetos deTransferencia

de Datos

V

C

M

DA

BD

V V V V

C C C C

M

M M M

DA DA DA DA

BD

Vistas

Controladores

Modelos

Data Accessors

Bases de Datos

Windows 8

Communication

& DataDevices

& Printing

WinRT APIsGraphics & Media

Desktop apps

CC++

Win32

C#VB

.NET SL

HTMLJavaScrip

t

Internet

Explorer

Metro style apps

Application Model

XAML

JavaScript

HTML / CSS

CC++

C#VB

Windows Kernel Services

Syst

em S

ervi

ces

View

Mod

el

Cont

rolle

rKe

rne

l

DX

Qué es ORM?Sección 2 de 5

Mapeo Objeto-RelacionalEs una técnica de programación para convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia.

ORMEn la práctica esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso de las características propias de la orientación a objetos (básicamente herencia y polimorfismo).

El problemaEn la programación orientada a objetos, las tareas de gestión de datos son implementadas generalmente por la manipulación de objetos, los cuales son casi siempre valores no escalares.

Sin embargo, muchos productos populares de base de datos, como los Sistemas de Gestión de Bases de Datos SQL, almacenan y manipulan valores escalares como enteros y cadenas organizados en tablas normalizadas. El programador debe convertir los valores de los objetos en grupos de valores simples para almacenarlos en la base de datos (y volverlos a convertir luego de recuperarlos de la base de datos), o usar sólo valores escalares simples en el programa. El mapeo objeto-relacional es utilizado para implementar la primera aproximación.

El núcleo del problema reside en traducir estos objetos a formas que puedan ser almacenadas en la base de datos para recuperarlas fácilmente, mientras se preservan las propiedades de los objetos y sus relaciones; estos objetos se dice entonces que son persistentes.

Desde el punto de vista de un programador, el sistema debe lucir como un almacén de objetos persistentes. Uno puede crear objetos y trabajar normalmente con ellos, los cambios que sufran terminarán siendo reflejados en la base de datos.Sin embargo, en la práctica no es tan simple. Todos los sistemas ORM tienden a hacerse visibles en varias formas, reduciendo en cierto grado la capacidad de ignorar la base de datos. Peor aún, la capa de traducción puede ser lenta e ineficiente (comparada en términos de las sentencias SQL que escribe), provocando que el programa sea más lento y utilice más memoria que el código "escrito a mano".

Motores de persistencia para ORM

Sección 3 de 5

Responsabilidades de un repositorio• Simular una colección en memoria a la

que podemos añadir o quitar objetos.• Permitir seleccionar un conjunto de

objetos a partir de distintos criterios.• Devolver objetos completamente

instanciados encapsulando la tecnología real de almacenamiento y consulta.

Curioso!Usando un ORM se consigue algo parecido. En el caso de NHibernate, es el objeto Isession, si es Entity Framework es, etcétera…

Ventajas•Simplifica la arquitectura de la aplicación, eliminado una capa que, desde su punto de vista, no aporta nada (los repositorios). •Permite una gran flexibilidad a la hora de realizar consultas, pudiendo seleccionar caso por caso los datos a cargar y las relaciones a navegar (en tanto y cuanto lo permita el ORM). •Permite sacar el máximo partido al ORM. El argumento es similar al de no abstraer el contenedor de IoC (pero en este caso el contenedor no se ve en ningún sitio de la aplicación), con este sistema el ORM sí se ve (y por todas partes).

IoCEn la ingeniería de software, Inversión de Control (IoC) es una práctica de programación orientada a objetos, donde se une el acoplamiento de objetos en tiempo de ejecución por un objeto ensamblador y normalmente no se conoce en tiempo de compilación utilizando el análisis de código estático (SCA).

IoCEl proceso de binding se logra a través de la inyección de dependencias, aunque hay quien afirma que el uso de un service locator también proporciona Inversión de Control.Para poder que el ensamblador ligue los objetos entre sí, los objetos deben poseer abstracciones compatibles. Por ejemplo, la clase A puede delegar el comportamiento a la interfaz I, que es implementada por la clase B; el ensamblador crea una instancia de A y B, para luego inyectar B en A.

Desventajas• El mayor inconveniente que tiene este

tipo de no-repositorio es que expone demasiada funcionalidad hacia las capas superiores de la aplicación.

• Infraestructura complicada (en algunos casos).

• Se necesita manejo de versiones acuciosa.

Frameworks o PlatformsExisten 10 tipos de desarrolladores… los que les agrada los Frameworks y los que les agrada las Platforms.

MS Des.

Platforms

Frameworks

48%36%

12%

Frameworks o PlatformsLos desarrolladores que gusten de platforms querrán usar SharePoint. Instalar. Personalizar. Ver a los usuarios finales colaborar en hojas de cálculo sobre datos obtenidos con Analysis Services.Los desarrolladores que gusten de frameworks querrán utilizar MVC. Es ligero. Es extensible. Se obtiene completo control.

Frameworks o Platforms

MVC

Shar

epoin

t

Web

Form

s

Framework Platform

Pregunta…

Podríamos combinarlos?

MotoresTecnología Licencia Nombre

.NET Castle Project MonoRail

.NET Apache Spring .NET

.NET Apache Maverick .NET

.NET MS-PL ASP.NET MVC

.NET Microsoft Patterns & Practices

User Interface Process (UIP) Application Block

ORMs vs MicroORMs vs ADO.NETLos DataReaders son siempre la opción más eficiente pero también la más laboriosa, así que sólo los utilizaría como último recurso. Tras ellos, los MicroORMs suelen ser bastante más rápidos que los ORMs, fundamentalmente porque hacen muchas menos cosas: no tienen identity map, no gestionan relaciones, no tienen lazy load, etc.

Sin embargo, cuando nos limitamos a cargar datos (no entidades) y usamos proyecciones con sentencias SQL optimizadas “a mano” para sacar el máximo rendimiento de la base de datos, estamos evitando gran parte de la carga que introduce un ORM y ahí es donde me surge la duda: si tienes un dominio complejo en el que compensa usar un ORM, ¿merece la pena introducir un MicroORM sólo para las lecturas?

Cuándo usar un ORM?Por definición un ORM es una herramienta que permite mapear un modelo relacional a un modelo de objetos. Eso implica que para que tenga sentido usar un ORM necesitamos dos cosas: un modelo relacional y un modelo de objetos. Puede parece una tontería, pero es que muchas veces no se tiene (ni se necesita) un modelo real de objetos, sino simplemente una representación directa de las tablas, con clases que sólo actúan como meros contenedores de datos y sin apenas relaciones entre sí.

Una de las características más importantes de todo ORM que se precie es la implementación del identity map, que nos garantiza que cuando cargamos dos veces una misma entidad desde la base de datos obtenemos el mismo objeto.El otro aspecto fundamental de un ORM es la gestión del Unit of Work, que nos permite trabajar con los objetos en memoria y hacer el seguimiento de los cambios que hemos realizado.

Cuándo usar un MicroORM?Antes de nada, no existe el término MicroORM, porque realmente no se trata de un ORM. Si un ORM se encarga de salvar la impedancia entre dos modelos, un MicroORM lo único que hace es mover datos de un sitio a otro, pero usando el mismo modelo. Más que un ORM, un MicroORM es un DataMapper.

Dejando de lado la nomenclatura, un MicroORM también tiene su utilidad. Hay aplicaciones en las cuales no tiene sentido crear un modelo complejo de objetos y podemos limitarnos a replicar el modelo relacional en memoria. Para este tipo de aplicaciones, un MicroORM, o incluso Active Record, es una buena salida porque nos permite evitar código repetitivo y genera por nosotros gran parte de las sentencias SQL para leer y escribir en la base de datos.

En un MicroORM generalmente no tenemos implementación del identity map y, si existe, la implementación de Unit Of Work es bastante más básica que la de un ORM completo.

Cuándo usar ADO.NET?Otra alternativa es tirar por la calle de en medio y no emplear ninguna librería, sino usar directamente ADO.NET. La ventaja es que evitas tener más dependencias y puedes exprimir al máximo el rendimiento.

Sin embargo, usar ADO.NET me parece una pérdida de tiempo en la mayoría de los casos. Está claro que si tienes una aplicación sumamente sencilla que sólo usa una o dos tablas, es una opción viable, pero en cuanto la aplicación tiene un número razonable de tablas, resulta poco rentable.

Una situación bastante frecuente es empezar usando ADO.NET y acabar implementando nuestro propio pseudo MicroORM. Cuando uno ha escrito 15 veces el mismo código para pasar datos de un DataReader a objetos, empieza a plantearse si no se podría hacer por reflection, o mejor aún usando generación dinámica de código para no perder eficiencia.

Preparando VS para MVCSección 4 de 5

Qué instalo? Qué configuro?1) Visual Studio 2010 SP1 (v. 10.0.40219.1)2) MVC 33) Framework 3.54) Lenguaje utilizado: C#5) Windows 2008 R2 Enterprise SP16) Sharepoint Server 2010 SP1 (v.

14.0.6029.1000)

Creando el MVC WebpartSección 5 de 5

Q & A