Cómo crear tu primer MVC WebPart en Sharepoint 2010

1. Cómo crear tu primer MVC WebPart en Sharepoint 2010 Ing. Randall Barnett Villalobos, Mci DBA / Developer Instituto Costarricense de Electricidad

2. Preliminares Agile XP Scrum

3. Quées MVC? Sección 1 de 5

4. Esconfusoel 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".

5. Quéesel 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.

6. Modelo Esta 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.

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

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

9. Implementaciones Aunque se pueden encontrar diferentes implementaciones de MVC, los flujos más comunes son generalmente los siguientes: El Modelo Pasivo El Modelo Activo

10. El Modelo Pasivo Este 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.

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

12. Arquitectura del MVC ASP .NET MVC ASP .NET Webforms Toolkits para GUI del ASP.NET Runtime ASP .NET Core Servicios del core de ASP.NET como el caching, configuartion, etc. .NET Framework El Runtime normal de .NET.

13. Vista Controlador Objetos de Transferencia de Datos Modelo(s) Data Accessor(s) Base(s) de Datos

14. V V V V V Vistas C C C C C Controladores M Modelos M M M M DA DA DA DA DA Data Accessors BD BD Bases de Datos

15. Windows 8 Metro style apps Desktop apps View XAML DX Model Controller HTML JavaScript C# VB HTML / CSS C C++ JavaScript C C++ C# VB System Services WinRT APIs Application Model Devices & Printing Communication & Data Graphics & Media Windows Kernel Services Kernel .NET SL Internet Explorer Win32

16. QuéesORM? Sección 2 de 5

17. Mapeo Objeto-Relacional Es 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.

18. ORM En 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).

19. El problema En 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.

20. 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.

21. 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.

22. 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".

23. Motores de persistenciapara ORM Sección 3 de 5

24. 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.

25. Curioso! Usando un ORMse consigue algo parecido. En el caso de NHibernate, es el objeto Isession, si es EntityFramework es, etcétera…

26. 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).

27. IoC En 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).

28. IoC El proceso de binding se logra a través de la inyección de dependencias, aunque hay quien afirma que el uso de un servicelocatortambié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.

29. 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.

30. Frameworks o Platforms Existen 10 tipos de desarrolladores… los que les agrada los Frameworksy los que les agrada las Platforms. Platforms MS Des. 12% 48% Frameworks 36% .03x

31. Frameworks o Platforms Los 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 AnalysisServices. Los desarrolladores que gusten de frameworks querrán utilizar MVC. Es ligero. Es extensible. Se obtiene completo control.

32. Frameworks o Platforms Web Forms Sharepoint MVC Framework Platform

33. Pregunta… Podríamos combinarlos?

34. Motores

35. ORMs vs MicroORMsvs ADO.NET Los DataReadersson 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 identitymap, no gestionan relaciones, no tienen lazy load, etc.

36. 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?

37. 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í.

38. Una de las características más importantes de todo ORM que se precie es la implementación del identitymap, 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.

39. 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.

40. 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.

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

42. 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.

43. 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.

44. Una situación bastante frecuente es empezar usando ADO.NET y acabar implementando nuestro propio pseudoMicroORM. 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.

45. Preparando VS para MVC Sección 4 de 5

46. Qué instalo? Qué configuro? Visual Studio 2010 SP1 (v. 10.0.40219.1) MVC 3 Framework 3.5 Lenguajeutilizado: C# Windows 2008 R2 Enterprise SP1 Sharepoint Server 2010 SP1 (v. 14.0.6029.1000)

47. Creando el MVC Webpart Sección 5 de 5

48. Q & A