Centro de Estudios de Postgrado
Centro de Estudios de Postgrado
Trabajo Fin de Máster
LA PLATAFORMA . NET .
TECNOLOGÍAS Y COMPONENTES
Alumno/a: Moreno Arjonilla, Jesús
Tutor/a: Prof. D. Rafael Segura Sánchez Dpto: Departamento de Informática
Junio, 2022
Contenido
RESUMEN ... 3
ABSTRACT ... 3
PALABRAS CLAVE ... 4
KEYWORDS ... 4
CAPÍTULO 1: INTRODUCCIÓN ... 5
CAPÍTULO 2: FUNDAMENTACIÓN EPISTEMOLÓGICA ... 6
2.1 ANTECEDENTES Y CONTEXTUALIZACIÓN ... 6
2.1.1 .NET Framework ... 8
2.1.1.1 Common Language Runtime (CLR) ... 9
2.1.1.2 La biblioteca de clases de .NET Framework ... 12
2.1.2 Mono/Xamarin ... 20
2.1.3 .NET Core ... 22
2.1.3.1 .NET Standard ... 25
2.1.3.2 ASP.NET Core ... 25
2.1.3.3 Entity Framework Core ... 28
2.1.3.4 .NET ... 29
2.2 TENDENCIAS FUTURAS ... 33
2.3 CONCLUSIÓN ... 35
CAPÍTULO 3: PROYECCIÓN DIDÁCTICA ... 37
3.1 INTRODUCCIÓN ... 37
3.2 UBICACIÓN DE LA ENSEÑANZA ... 37
3.3 NORMATIVA ... 38
3.4 CONTEXTO ... 38
3.4.1 Contexto socioeconómico del centro ... 38
3.4.2 Características del centro ... 40
3.4.3 Características del alumnado ... 41
3.5 OBJETIVOS ... 42
3.5.1 Competencia general del título ... 42
3.5.2 Competencias profesionales, personales y sociales de la U.D. (C.P.P.S.) ... 42
3.5.3 Orientaciones pedagógicas (O.P.) de la U.D. ... 43
3.5.4 Líneas de actuación del módulo (L.A.) ... 43
3.5.5 Objetivos generales del ciclo formativo (O.G.C.F.) trabajados en la U.D. ... 43
3.5.6 Resultados de aprendizaje (R.A.) de la U.D. ... 44
3.5.7 Criterios de evaluación de la U.D. ... 44
3.5.10 Objetivos didácticos de la unidad (O.D.) ... 45
3.6 CONTENIDOS ... 45
3.6.1 Contenidos generales ... 45
3.6.2 Contenidos específicos ... 46
3.6.3 Interdisciplinariedad ... 46
3.6.4 Tema/s transversal/es o educación en valores ... 47
3.7 METODOLOGÍA ... 47
3.7.1 Materiales y recursos de la U.D. ... 48
3.7.2 Organización del espacio ... 48
3.7.3 Actividades de Enseñanza-Aprendizaje ... 49
3.7.4 Tabla de actividades de enseñanza-aprendizaje ... 50
3.8 EVALUACIÓN ... 52
3.8.1 Instrumentos de evaluación ... 52
3.8.2 Ponderación ... 52
3.8.3 Evaluación inicial ... 53
3.8.4 Evaluación continua ... 53
3.8.5 Evaluación final ... 53
3.8.6 Recuperación ... 53
3.8.7 Evaluación del proceso de enseñanza ... 54
3.9 ATENCIÓN A LA DIVERSIDAD ... 54
3.9.1 Ritmos de aprendizaje ... 54
3.9.2 Necesidades educativas especiales (NEE) ... 54
3.10 TABLA RESUMEN DE LA U.D. ... 56
3.11 BIBLIOGRAFÍA DE DEPARTAMENTO ... 57
3.12 BIBLIOGRAFÍA DE AULA ... 58
BIBLIOGRAFÍA ... 59
ANEXOS ... 65
ANEXO I:INSTALACIÓN DE VISUAL STUDIO Y FRAMEWORKS ADICIONALES. ... 65
ANEXOII:EJEMPLO DE APLICACIÓN PARA DISPOSITIVOS MÓVILES CON XAMARIN Y XAMARIN.FORMS ... 65
ANEXO III:EJEMPLO DE APLICACIÓN ASP.NETMVC ... 71
ANEXOIV:EJEMPLO DE DESARROLLO DE JUEGOS MULTIPLATAFORMA CON UNITY. ... 75
1
Índice de figuras
FIGURA 1:COMPONENTES FUNDAMENTALES DE .NET ... 8
FIGURA 2: PARTES PRINCIPALES DE .NET FRAMEWORK ... 9
FIGURA 3:ALGUNOS ESPACIOS DE NOMBRES DE LA BIBLIOTECA DE CLASES DE .NET FRAMEWORK ... 13
FIGURA 4:FRAMEWORKS PRINCIPALES DE ASP.NET ... 16
FIGURA 5:ESTRUCTURA DEL MODELO DE OBJETOS DE ADO.NET ... 17
FIGURA 6:COMPONENTES DE XAMARIN ... 22
FIGURA 7: ARQUITECTURA DE .NET STANDARD ... 25
FIGURA 8: IMAGEN COMPARATIVA ENTRE .NET CORE Y .NET FRAMEWORK ... 26
FIGURA 9: FRAMEWORKS MÁS QUERIDOS EN 2021 ... 31
FIGURA 10:FRAMEWORKS WEB MÁS QUERIDOS EN 2021... 32
FIGURA 11: IDES MÁS QUERIDOS EN 2021 ... 32
FIGURA 12: LENGUAJES MÁS QUERIDOS EN 2021 ... 33
FIGURA 13: LOCALIZACIÓN DEL IES LA PEÑA ... 39
FIGURA 14: DISTRIBUCIÓN DEL AULA ... 49
FIGURA 15: INSTALACIÓN DE VISUAL STUDIO Y FRAMEWORKS ADICIONALES... 65
FIGURA 16: CREAR UN NUEVO PROYECTO EN VISUAL STUDIO ... 66
FIGURA 17: CREAR APLICACIÓN MÓVIL CON XAMARNI Y XAMARIN.FORMS ... 66
FIGURA 18: PLANTILLA DE APLICACIÓN MÓVIL CON XAMARIN ... 67
FIGURA 19: ESTRUCTURA DE UN PROYECTO XAMARIN.FORMS ... 67
FIGURA 20: AGREGAR UNA NUEVA PÁGINA DE CONTENIDOS A NUESTRA APLICACIÓN ... 68
FIGURA 21: FICHERO .XML ... 68
FIGURA 22: FICHERO .CS ... 69
FIGURA 23: CREACIÓN DE UN BOTÓN ... 69
FIGURA 24: GESTIÓN DE EVENTO “CLICK” ... 70
FIGURA 25: ADMINISTRADOR DE DISPOSITIVOS ANDROID... 70
FIGURA 26: EJECUCIÓN DE LA APLICACIÓN ... 71
FIGURA 27: CREACIÓN DE PROYECTO ASP.NET MVC ... 72
FIGURA 28: ESTRCUTURA DE UN PROYECTO ASP.NET MVC ... 72
FIGURA 29: CONTENIDO DE LA CARPETA “CONTROLLERS” ... 73
FIGURA 30: CONTENIDO DEL ARCHIVO “HOMECONTROLLER.CS” ... 73
FIGURA 31: CONTENIDO DE LA CARPETA “MODELS” ... 73
FIGURA 32: CONTENIDO DEL ARCHIVO “ERRORVIEWMODEL.CS” ... 74
FIGURA 33:“CONTENIDO DE LA CARPETA “VIEWS” ... 74
FIGURA 34: CONTENIDO DEL ARCHIVO “INDEX.CSHTML” DE “HOME” ... 74
FIGURA 35: CAMBIOS REALIZADOS A LA VISTA HOME ... 75
FIGURA 36: EJECUCIÓN DE LA APLICACIÓN ... 75
FIGURA 37: CREACIÓN DE UN PROYECTO EN UNITY ... 76
FIGURA 38: CREACIÓN DE UN EJECUTABLE PARA CADA PLATAFORMA ... 76
FIGURA 39: COMPROBACIÓN DE LA PLATAFORMA DE EJECUCIÓN ... 77
2
Índice de tablas
TABLA 1:ACTIVIDADES DE ENSEÑANZA-APRENDIZAJE ... 50 TABLA 2:PONDERACIONES ... 53 TABLA 3:RESUMEN DE LA UNIDAD DIDÁCTICA. ... 56
3
Resumen
En este documento se desarrolla el Trabajo Fin de Máster (TFM) del Máster Universitario en Profesorado de Educación Secundaria Obligatoria y Bachillerato, Formación Profesional y Enseñanza de Idiomas de la Universidad de Jaén. Su título, “La plataforma .NET. Tecnologías y componentes” indica la temática que se va a seguir tanto en el estudio teórico como en el desarrollo de la unidad didáctica.
El documento se divide en dos partes. En la primera parte se realiza una investigación sobre la temática del TFM, la plataforma de .NET. En ella se analiza el origen de la tecnología, su evolución, posibles tendencias futuras y se finaliza con una conclusión personal.
La segunda parte de este documento consiste en plasmar los conocimientos adquiridos en la primera parte en una unidad didáctica, indicando su contextualización, temporalización, metodología a seguir y evaluación, todo ello bajo la normativa vigente del curso 2021/2022. La unidad didáctica desarrollada en este trabajo se llama
“Desarrollo de aplicaciones para dispositivos móviles con Xamarin y Xamarin.Forms” y está englobada dentro del módulo de “Programación multimedia y dispositivos móviles”
perteneciente al segundo curso del Ciclo Formativo de Grado Superior de Desarrollo de Aplicaciones Multiplataforma.
Abstract
This document develops the Master's Thesis of the Master's Degree in Compulsory Secondary Education and Baccalaureate, Vocational Training and Language Teaching of the University of Jaén. Its title, "The .NET platform. Technologies and components" indicates the theme that is going to be followed both in the theoretical study and in the development of the didactic unit.
The document is divided into two parts. In the first part, a research on the subject of the Master’s Thesis, the .NET platform, is carried out. It analyzes the origin of the technology, its evolution, possible future trends and ends with a personal conclusion.
The second part of this document consists of aplying the knowledge acquired in the first part in a didactic unit, indicating its contextualization, timing, methodology to be followed and evaluation, all under the current regulationsof the 2021/2022 course.
The didactic unit developed in this work is called "Applications development for mobile devices with Xamarin and Xamarin.Forms" and is included in the module "Multimedia programming and mobile devices" belonging to the second course of the Higher Level Training Cycle of Multiplatform Applications Development.
4
Palabras clave
Desarrollo multiplataforma, frameworks multiplataforma, .NET, desarrollo de aplicaciones móviles multiplataforma, Xamarin, Xamarin.Forms.
Keywords
Cross-platform development, cross-platform frameworks, .NET, cross-platform mobile application development, Xamarin, Xamarin.Forms.
5
Capítulo 1: Introducción
Este trabajo Fin de Máster supone el fin de una etapa de formación recibida en el Máster Universitario en Profesorado de Educación Secundaria Obligatoria y Bachillerato, Formación Profesional y Enseñanza de Idiomas de la Universidad de Jaén, la cual nos prepara para ser futuros docentes.
Este documento está dividido en dos bloques principales. En primer lugar, nos encontramos con un apartado donde se elabora una fundamentación epistemológica sobre un tema dado. En este trabajo se realiza una investigación sobre la plataforma .NET y sus principales componentes, partiendo desde su origen, en 2002, como una plataforma creada por Microsoft para construir aplicaciones, componentes y servicios basados en Windows y en la web utilizando diversos lenguajes de programación.
Después, analizamos su evolución hasta convertirse en la plataforma para el desarrollo de aplicaciones multiplataforma que conocemos en la actualidad. Por último, se discuten posibles tendencias futuras y se concluye con un resumen de los aspectos más importantes de esta tecnología y una opinión personal.
La segunda parte de este documento consiste en una proyección didáctica de la tecnología analizada en el bloque anterior. Para ello, los conocimientos adquiridos en el trabajo epistemológico han de ser enmarcados en una unidad didáctica que pueda llevarse al aula. En este trabajo, la unidad didáctica creada se ha nombrado “Desarrollo de aplicaciones para dispositivos móviles con Xamarin y Xamarin.Forms” y pertenece al segundo año del Ciclo Formativo de Grado Superior (C.F.G.S.) de Desarrollo de Aplicaciones Multiplataforma (DAM), el cual forma parte de la etapa de Formación Profesional (FP). En cuanto al curso académico, toda la proyección didáctica se ha realizado para el curso 2021/2022 por lo que la normativa que se ha utilizado para este apartado es la normativa vigente para dicho curso. Por último, el centro educativo en el cual se va a contextualizar esta unidad didáctica es el “IES La Peña” de Martos, centro en el cual realicé la Educación Secundaria Obligatoria (ESO).
6
Capítulo 2: Fundamentación epistemológica
En este capítulo vamos a realizar un recorrido por la historia de .NET. Veremos el por qué surge, cuándo surge y cómo ha ido evolucionando hasta día de hoy.
Posteriormente discutiremos sobre las posibles tendencias futuras de esta tecnología y como puede evolucionar a lo largo de los próximos años.
2.1 Antecedentes y contextualización
Para entender la importancia de .NET primero debemos de conocer las herramientas y plataformas de desarrollo de las que disponían los programadores antes de su aparición.
Tradicionalmente, el desarrollo de software para la familia de sistemas operativos Windows implicaba el uso del lenguaje C junto con la interfaz de programación de aplicaciones (API) de Windows. Si bien es cierto que se han creado aplicaciones de mucho éxito utilizando este enfoque, la creación de aplicaciones utilizando la API en bruto es una tarea compleja.
Una gran mejora con respecto al desarrollo utilizando C y una API es el uso del lenguaje C++. En muchos sentidos, C++ puede considerarse como una capa orientada a objetos sobre el lenguaje C. Así, aunque los programadores de C++ se benefician de los famosos pilares de la programación orientada a objetos, siguen estando a merced de aspectos complejos del lenguaje C como la gestión de memoria, la aritmética de punteros y las construcciones sintácticas.
Muchos programadores decidieron alejarse de C++ en búsqueda de una forma de desarrollar más sencilla y se pasaron a Visual Basic (VB). VB6 se hizo popular gracias a su capacidad de crear complejas interfaces de usuario, bibliotecas de código y lógica de acceso a bases de datos con un mínimo de complicaciones. Además, VB6 ocultaba las complejidades de la API de Windows mediante una serie de asistentes de código integrados, tipos de datos intrínsecos de VB, clases y funciones específicas. Sin embargo, la mayor desventaja de VB6 es que no es un lenguaje totalmente orientado a objetos, sino que se basa en ellos.
Hablando de Java, este es un lenguaje de programación orientado a objetos con sus raíces sintácticas en C++. Como lenguaje, Java limpia muchos aspectos desagradables de C++. Como plataforma, Java proporciona a los programadores un gran número de paquetes predefinidos que contienen varias definiciones de tipos. Utilizando estos tipos, los programadores de Java son capaces de construir aplicaciones completas con conectividad a bases de datos, soporte de mensajería, servicios web y una rica interfaz de usuario de escritorio. Sin embargo, aunque Java es un lenguaje muy elegante,
7
un problema potencial es que el uso de Java suele significar que hay que utilizarlo de principio a fin durante el desarrollo.
Por otro lado, tenemos el Modelo de Objetos Componentes (Component Object Model, COM) que fue el marco de desarrollo de aplicaciones de Microsoft anterior a .NET el cual apareció por primera vez hacia 1991. COM es una arquitectura en la cual, si construyes los tipos de acuerdo a las reglas COM, terminas generando un bloque de código binario reutilizable que recibía el nombre de “servidores COM”.
Una de las ventajas de un servidor COM binario es que se puede acceder a él de forma independiente al lenguaje. Así, los programadores de C++ pueden construir clases COM que pueden ser utilizadas por VB6, los programadores de Delphi pueden utilizar clases COM construidas con C y así sucesivamente. Sin embargo, la independencia del lenguaje COM es limitada ya que no existe manera de derivar una nueva clase COM utilizando otra clase ya existente, es decir, COM no tiene soporte para herencia.
Aunque COM puede ser considerado un modelo de objetos muy exitoso, es extremadamente complejo en su interior. Para ayudar a simplificar el desarrollo de binarios COM, los programadores pueden hacer uso de frameworks compatibles con COM, como por ejemplo Active Template Library (ATL), el cual proporciona un conjunto de clases, plantillas y macros de C++ para facilitar la creación de servidores COM.
Muchos otros lenguajes también ocultan una buena parte de la infraestructura COM. Sin embargo, el soporte del lenguaje no es suficiente para ocultar la complejidad de COM. Incluso cuando se elige un lenguaje relativamente sencillo como VB6, hay que lidiar con entrada de registro frágiles y numerosos problemas de despliegue (Troelsen, 2010).
Es por ello por lo que en 2002 Microsoft decide lanzar una nueva plataforma con un enfoque más radical para facilitar el trabajo a los desarrolladores, hablamos de .NET, una plataforma creada para construir aplicaciones, componentes y servicios basados en Windows y en la web mediante el uso de diversos lenguajes de programación (Joshi, 2007). Junto con esta plataforma, Microsoft introdujo un nuevo lenguaje de programación llamado C#, el cual se convirtió en el lenguaje principal para desarrollar aplicaciones en .NET.
La plataforma .NET está formada por 5 componentes fundamentales que pueden verse en la Figura 1 (Thai, 2003):
• En la capa más baja tenemos el sistema operativo, al cual podía ser cualquiera de las plataformas de Windows como Windows XP, Windows 2000, Windows Server, Windows Me o Windows CE.
• Encima del sistema operativo encontramos una colección de servidores especializados que disminuyen el tiempo necesario para desarrollar sistemas
8
empresariales a gran escala. Entre estos servidores encontramos servidores SQL, servidores para comercio, servidores Biztalk 1, etc.
• Dado que los servicios web son muy reutilizables, Microsoft también tenía previsto ofrecer una serie de bloques de servicios que los desarrolladores podían pagar por utilizar. Un ejemplo de esto es el Microsoft Passport, que permite utilizar un único nombre de usuario y contraseña en todos los sitios webs que admitieran la autenticación con Passport.
• En el centro de la plataforma .NET encontramos el .NET Framework el cual consiste en una nueva infraestructura para el desarrollo y ejecución de aplicaciones empresariales para la plataforma Windows. Este incluye el Common Language Runtime (CLR) y un marco común de clases que pueden utilizar todos los lenguajes .NET.
• En la capa más alta encontramos una nueva herramienta de desarrollo llamada Visual Studio.NET (VS.NET), que hace posible el desarrollo rápido de servicios web y otras aplicaciones. VS.NET, sucesor de Microsoft Visual Studio, era un entorno de desarrollo integrado (IDE) que admitía cuatro lenguajes de programación diferentes (C#, J#, C++, Visual Basic.NET) y funciones como la depuración entre idiomas y el editor de esquemas XML.
Figura 1
Componentes fundamentales de .NET.
2.1.1 .NET Framework
Para los desarrolladores, lo más importante de toda esta plataforma .NET era el .NET Framework. Este fue lanzado por primera vez en 2002 en su versión 1.1 y supuso un gran cambio para quienes escribían software para Windows. Desde entonces ha ido evolucionando hasta alcanzar su última versión (4.8) publicada en 2019.
1Un servidor Biztalk es un producto middleware de Microsoft que ayuda a conectar varios sistemas entre sí. Conecta diversos programas informáticos y permite crear y modificar la lógica de los procesos que utilizan estos programas (Introducing BizTalk Server - BizTalk Server, 2022; KamleshKumar, 2022).
9
Las dos partes principales del framework eran el CLR y la biblioteca de clases.
Una aplicación .NET siempre utiliza el CLR y también puede utilizar cualquier parte de la biblioteca de clases que necesite (ver Figura 2) (Chappell, 2006).
Figura 2
Partes principales de .NET Framework
Todas las aplicaciones escritas con el Framework dependen del CLR. Entre otras cosas, este proporciona un conjunto común de tipos de datos que actúa como base para C#, Visual Basic y todos los demás lenguajes soportados por .NET Framework.
2.1.1.1 Common Language Runtime (CLR)
El Common Language Runtime (CLR) es un componente clave del .NET Framework. Es el contenedor o entorno de ejecución en el que se ejecuta todo el código.
En funcionalidad y naturaleza, es similar al Java Virtual Machine (JVM). Se sitúa entre el código y el sistema operativo de modo que el código no interactúa directamente con este. Esta disposición hace que el código sea portable hasta cierto punto y también libera al desarrollador de tener que hacer tareas a nivel de sistema (Puvvala, 2004).
El CLR proporciona servicios de infraestructura para apoyar la ejecución del código. Estos servicios son (Lenz, 2004):
10
Manejo de la ejecución
Las aplicaciones .NET están formadas por uno o varios de los llamados ensamblajes. Un ensamblaje es una agrupación lógica de módulos (archivos de código o recursos) que contienen metadatos que los autodescriben. Por lo tanto, el CLR conoce las dependencias de un ensamblaje sin depender de información externa, como la configuración de un registro. Esto también hace que sea más fácil desplegar ensamblajes para desplegar código que no esté gestionado por el CLR.
El código dentro de los ensamblajes no es código máquina nativo, sino que es de un lenguaje intermedio, Este lenguaje es independiente de la CPU de la plataforma destino y, comparado con el código máquina nativo, es de más alto nivel. Cuando se compila el código fuente de .NET (como Visual Basic o C#), el compilador genera módulos de programas que contienen metadatos y el lenguaje intermedio, y se vincula a los ensamblajes. Sólo después de que el CLR cargue un ensamblaje en la plataforma de destino, el compilador Just-In-Time (JIT) compila el lenguaje intermedio en código máquina. El despliegue de código en lenguaje intermedio también permite al compilador JIT optimizar el código para la plataforma en la que se ejecuta.
Independencia del lenguaje
.NET Framework ofrece a los desarrolladores la flexibilidad de escribir programas en uno de los muchos lenguajes para los que existe un compilador compatible con .NET. Todos los lenguajes de programación .NET se ajustan a un modelo común de Programación Orientada a Objetos (POO) que admite la herencia única de clases, la herencia múltiple de interfaces y el polimorfismo entre otras características.
Gracias a este modelo común, las clases pueden incluso heredar o capturar excepciones de clases escritas por otro lenguaje. Otra característica importante del CLR es el Common Type System (CTS), que proporciona un conjunto común de tipos de datos a todos los lenguajes .NET. La facilidad con la que una aplicación puede estar compuesta por módulos escritos en diferentes lenguajes de programación es una gran ventaja del CLR. Algunos de los lenguajes para los que Microsoft proporciona compiladores son: C++
(con extensiones), C#, Visual Vasic.NET, JScript, J#. Además, existen compiladores de otras compañías para lenguajes como COBOL, Delphi, Pascal, Python, etc.
Interoperabilidad entre plataformas
Una de las principales razones del éxito de Java es su independencia de plataforma. En java es posible escribir código, compilarlo y enviarlo. Este código se puede ejecutar en cualquier máquina o, lo que es lo mismo, en cualquier sistema operativo que tenga una máquina virtual de Java en funcionamiento. Al igual que con Java, el código compilado de .NET puede ejecutarse en cualquier plataforma habilitada para .NET. La ventaja de .NET frente a Java es que se puede utilizar cualquier lenguaje
11
de programación .NET con el .NET Framework, mientras que la máquina virtual de Java solo admite el lenguaje Java. Sin embargo, .NET Framework y su biblioteca de clases solo es soportada por el sistema operativo Windows.
Recolección de basura
Todas las aplicaciones utilizan recursos como buffers de memoria, conexiones de red o de bases de datos, etc.
La creación y cierre de estos recursos siguen siendo responsabilidad del programador, pero el CLR ofrece una gestión automática de la memoria para asignar la memoria del objeto que representa un recurso y liberarla. De hecho, muchos objetos solo requieren memoria y no tratan directamente con otros recursos del sistema. Estos objetos son gestionados completamente por el CLR.
Seguridad
El CLR proporciona seguridad de acceso al código para los ensamblajes que se ejecutan. Tradicionalmente, una cuenta de usuario que iniciaba una aplicación decidía si concedía permisos para acceder a determinados recursos del sistema. Esto funcionaba bien siempre que el origen de las aplicaciones fuera conocido y de confianza. Sin embargo, con desarrollos como las capacidades de scripting de los navegadores web y la instalación bajo demanda de componentes adicionales, se vio necesario establecer permisos de seguridad de forma dinámica para las diferentes aplicaciones.
En .NET cada ensamblaje contiene información sobre el tipo de acceso que requiere y el CLR comprueba estos con los permisos concedidos que se heredan de una variedad de reglas.
Control de versiones
Las bibliotecas de enlace dinámico, también conocidas como DLL (Dynamic Link Libraries), se introdujeron para ahorrar espacio en disco y memoria. Las piezas comunes de código que son utilizadas por varias aplicaciones se despliegan en forma de DLL y el sistema operativo se encarga de cargar cada DLL sólo una vez en memoria. Sin embargo, cuando una aplicación se actualizaba, solía conllevar también una actualización de la DLL. Pero sobrescribir una DLL puede impedir que otras aplicaciones funcionen, dando lugar a lo que se conoce como el infierno de DLL.
Para solucionar esto .NET Framework distingue entre ensamblajes privados y compartidos. Los ensamblajes privados residen en el mismo directorio que el ejecutable del programa y se identifican por el nombre del archivo de ensamblaje. A estos ensamblajes no se les aplica ningún tipo de control de versiones ya que son utilizados únicamente por una aplicación y no pueden verse afectados por los cambios realizados en el sistema o en otras aplicaciones. Sin embargo, los ensamblajes compartidos
12
requieren de nombres únicos globales y deben soportar la ejecución side-by-side, es decir, la capacidad de instalar y ejecutar múltiples versiones de un componente en la misma máquina al mismo tiempo, incluso dentro del mismo proceso. El CLR asegura que, por defecto, la única versión cargada de un ensamblaje es aquella con la que se construyó la aplicación.
Despliegue y actualizaciones simplificadas
Desplegar una aplicación .NET puede ser tan fácil como copiar el directorio de la aplicación en el ordenador de destino, aunque también puede crearse un instalador de Windows. Del mismo modo, desinstalar una aplicación puede hacerse borrando este directorio.
Gestión de excepciones
En .NET todos los fallos en las llamadas a métodos se notifican mediante excepciones. Además, las excepciones pueden pasarse entre módulos suponiendo una ventaja para las aplicaciones que contienen módulos escritos en diferentes lenguajes.
2.1.1.2 La biblioteca de clases de .NET Framework
La biblioteca de clases de .NET Framework consiste en una biblioteca de clases y otros tipos que los programadores pueden utilizar que les facilita el desarrollo de aplicaciones. Aunque estas clases están escritas en C#, pueden utilizarse desde cualquier lenguaje basado en el CLR. El código escrito en C#, C++, Visual Basic o cualquier otro lenguaje compatible con .NET puede crear instancias de estas clases y realizar llamadas a sus métodos. Ese código también puede hacer uso del soporte del CLR para la herencia y heredar de clases de la biblioteca.
El contenido de la biblioteca de clases de .NET Framework está organizado en un árbol de espacios de nombres. Cada espacio de nombres puede contener tipos, como clases e interfaces, y otros espacios de nombres. En la Figura 3 muestro algunos espacios de nombres que explico a continuación (Chappell, 2006):
• System: Es la raíz del árbol, este espacio de nombres contiene a todos los demás espacios de nombres de la biblioteca de clases de .NET Framework. System también contiene los tipos de datos básicos utilizados por el CLR y, por tanto, por los lenguajes construidos sobre el CLR.
• System.Web: Este espacio de nombres contiene tipos útiles para crear aplicaciones web y, como muchos espacios de nombres, contiene a otros espacios de nombres. Los desarrolladores pueden utilizar los tipos de System.Web.UI para crear aplicaciones de navegador ASP.NET, por ejemplo, mientras que los de System.Web.Services se utilizan para crear aplicaciones de servicios web ASP.NET.
13
• System.Data: Los tipos de este espacio de nombres conforman ADO.NET. Por ejemplo, la clase Connection se utiliza para realizar conexiones con un sistema de gestión de bases de datos (SGBD). Mientras que una instancia de la clase DataSet puede utilizarse para almacenar en caché y examinar los resultados de una consulta realizada sobre ese SGBD.
• System.Windows.Forms: Los tipos de este espacio de nombres conforman Windows Forms y se utilizan para construir interfaces gráficas de Windows. En lugar de depender de mecanismos específicos del lenguaje, como las antiguas Microsoft Fundation Classes (MFC) en C++, las aplicaciones de .NET Framework escritas en cualquier lenguaje de programación utilizan este conjunto común de tipos para construir interfaces gráficas para Windows.
• System.EnterpriseServices: Los tipos de este espacio de nombres proporcionan los servicios necesarios para algunas aplicaciones empresariales. Estos servicios incluyen transacciones distribuidas, gestión del tiempo de vida de las instancias de los objetos, entre otros. El tipo más importante de este espacio de nombres, del que deben heredar las clases para utilizar los servicios empresariales, es la clase ServicedComponent.
• System.XML: Los tipos de este espacio de nombres proporcionan soporte para crear y trabajar con datos definidos por XML. La clase XmlDocument, por ejemplo, permite acceder a un documento XML utilizando el Document Object Model (DOM). Este espacio de nombres también incluye soporte para las tecnologías como el lenguaje de definición de esquemas XML (XSD) y XPath.
Figura 3
Algunos espacios de nombres de la biblioteca de clases de .NET Framework
Dentro de todo el conjunto de bibliotecas de .NET Framework, en este documento vamos a hablar de tres de las más importantes: ASP.NET, ADO.NET y Windows Forms.
14
ASP.NET
Para entender ASP.NET primero debemos de comprender cual fue su antecesor, ASP y los problemas que presentaba. Microsoft ASP (Active Server Pages) es una tecnología de scripts del lado del servidor que permitía crear páginas webs dinámicas.
Una página ASP contiene marcas HTML y scripts del lado del servidor que generan contenido de forma dinámica. Los scripts del servidor se ejecutan cuando una solicitud de la página ASP llega al servidor a través de una petición POST o GET. ASP proporciona un modelo de objetos para simplificar las tareas de los desarrolladores. Además de los objetos del modelo de objetos ASP como Application, Server, Request, Response y Session, los desarrolladores pueden utilizar cualquier componente COM en el servidor.
Sin embargo, ASP presentaba algunos problemas como los que enumero a continuación (Thai, 2003):
• Era fácil acabar con marcas HTML y scripts del lado del servidor entrelazados que generaban conflictos.
• El modelo de encapsulación de las páginas ASP era pobre y dificultaba su gestión y su reutilización.
• A la hora de trabajar con aplicaciones web para varios navegadores había problemas a la hora de generar el HTML según la capacidad de navegación del cliente. Muchas veces se generaban las etiquetas HTML y los scripts del lado del cliente más simples para asegurarse de que podían ser entendidos por muchos navegadores.
• El scripting de ASP solo está disponible para lenguajes de última generación como VBScript y JavaScript.
• No había seguridad de tipos.
• Los scripts del lado del servidor se reinterpretan cada vez que se accede a la página, lo que no es ideal para el rendimiento.
• El mantenimiento del estado de los formularios en una aplicación basada en ASP requiere de mucho trabajo. Los desarrolladores deben de hacerlo todo manualmente, incluido el reenvío de datos, el uso de campos ocultos y las variables de sesión.
ASP.NET surgió a partir de ASP para superar la mayoría de sus carencias.
ASP.NET es la base de .NET Framework para crear aplicaciones web.
Implementado principalmente como parte de la biblioteca de clases de .NET Framework, permite crear tanto aplicaciones de navegador como aplicaciones de servicios web.
ASP.NET define un grupo de tipos almacenados en varios espacios de nombres. El espacio de nombre raíz de ASP.NET es System.Web, e inmediatamente por debajo hay varios espacios de nombres más. Los más importantes son System.Web.UI, que contiene los tipos utilizados para crear aplicaciones web de navegador, y System.Web.Services,
15
que contiene los tipos utilizados para construir aplicaciones de servicios web (Chappell, 2006).
Como diferencias frente a ASP, ASP.NET ofrece (Parsons, 2008):
• El código de ASP.NET es C# mientras que en ASP es VBScript.
• Seguridad de tipos. A diferencia de ASP, cada variable que se declare en ASP.NET debe tener un tipo asociado. Esto se debe a que todos los lenguajes que se pueden utilizar para crear aplicaciones en ASP.NET son lenguajes fuertemente tipados.
• Código compilado en vez de interpretado. ASP.NET se aleja del modelo de código interpretado de ASP y en su lugar se ejecuta a partir de código compilado gracias al CLR. Al comenzar a escribir y construir aplicaciones ASP.NET, éstas se compilarán finalmente en un .dll que contiene Microsoft Intermediate Language (MSIL), que es un tipo especial de código. Cuando se solicita una página por primera vez, este código MSIL se compila en código máquina nativo mediante el compilador JIT del CLR, produciendo un código optimizado para el rendimiento.
• El entorno de desarrollo. ASP se programaba utilizando el bloc de notas de Windows, sin embargo, el entorno de desarrollo recomendado por Microsoft para ASP.NET es Visual Studio, aunque su uso es completamente opcional. Una de las ventajas de utilizar Visual Studio es que es un IDE completo lo que significa que puedes desarrollar y probar tu sitio web sin tener que salir del programa.
• Aplicaciones orientadas a objetos y dirigidas por eventos. Las aplicaciones ASP.NET están orientadas a objetos y dirigidas por eventos. Esto significa que cuando se hace click en un botón, por ejemplo, de envío, se genera un evento de click que puede ser manejado por el desarrollador. En otras palabras, se puede crear un método que ejecutará cierto código cuando se haga click en dicho botón.
A su vez, ASP.NET ofrece tres framework para crear aplicaciones web (ver Figura 4) (ASP.NET Overview, 2022):
• Web Forms: El enfoque original y el más común para desarrollar con ASP.NET es utilizando Web Forms, que es similar a lo que VB dio a los desarrolladores de Windows. Cada objeto de una página es programable y tiene eventos. Este enfoque es muy sencillo, se colocan objetos en una superficie de diseño y se programan, utilizando un método similar al del desarrollo clásico de aplicaciones de escritorio. Sin embargo, las aplicaciones del mundo real suelen ser más complejas y en algunos casos pueden necesitar tener más control sobre la salida.
En esos casos, este enfoque para definir una página puede resultar poco flexible.
Es por ello por lo que surge una nueva alternativa, ASP.NET MVC (Bochicchio, 2011).
16
• MVC: Este enfoque te da más flexibilidad a la hora de desarrollar una web, pero necesitas realizar más implementación que con los Web Forms. Fue creado para apoyar el desarrollo de software basado en patrones, es decir para facilitar la aplicación de los principios y patrones de diseño del software a la hora de crear aplicaciones web. Además, este framework fue diseñado en su núcleo para soportar pruebas unitarias por lo que las webs escritas con ASP.NET MVC son totalmente comprobables (Walther, 2009).
• Web Pages: Permite la creación de webs dinámicas (Web Pages - Getting Started, 2020).
Figura 4
Frameworks principales de ASP.NET
ADO.NET
Antes de la introducción de .NET Framework Microsoft disponía de una tecnología de acceso a datos denominada Active Data Object (ADO). ADO ha sido muy útil los desarrolladores, pero carece de características muy importantes que los desarrolladores necesitan para crear aplicaciones más potentes. Por ejemplo, en sus primeras versiones, ADO no permitía trabajar con datos XML, algo que cada vez más desarrolladores utilizan. Microsoft añadió esta funcionalidad en versiones posteriores de ADO, sin embargo, esta tecnología nunca manejará datos XML de forma tan eficiente a como lo haría un framework que fue diseñado teniendo el manejo de datos con XML en mente. Entre otros problemas, ADO no permite combinar contenidos de varios objetos RecordSet ni tener control sobre la lógica utilizada para enviar actualizaciones a la base de datos. Tampoco proporciona una forma de enviar los cambios pendientes a la base de datos a través de procedimientos almacenados. Por ello, Microsoft decidió construir ADO.NET y resolver todos estos problemas.
ADO.NET fue diseñado para combinar las mejores características de sus predecesores, al mismo tiempo que añade nuevas funciones solicitadas por los
17
desarrolladores como son: mayor compatibilidad con XML, acceso más sencillo a los datos desconectados y mayor flexibilidad.
ADO.NET es un conjunto de bibliotecas incluidas en .NET Framework que ayudan a comunicarse con varios almacenes de datos desde las aplicaciones. Estas bibliotecas incluyen clases para conectarse a bases de datos, realizar consultas y procesar los resultados obtenidos. ADO.NET también puede ser utilizado como una caché jerárquica y robusta de datos para trabajar sin conexión. El objeto central, denominado DataSet, permite buscar, filtrar, ordenar, almacenar los cambios pendientes y navegar por los datos jerárquicos. Este objeto también incluye una serie de funciones que acortan las distancia entre el acceso tradicional a los datos y el desarrollo XML. De esta forma, los desarrolladores pueden trabajar con datos XML a través de interfaces de acceso a datos tradicionales y viceversa (Sceppa, 2009).
ADO.NET fue diseñado con el objetivo de ayudar a los desarrolladores a crear aplicaciones de bases de datos eficientes en múltiples niveles a través de intranets e Internet. Para ello, se creó un modelo de objetos ADO.NET que podéis ver en la Figura 5.
Figura 5
Estructura del modelo de objetos de ADO.NET
El modelo de objetos de ADO.NET abarca dos grupos distintos de clases: los componentes de contenido y los componentes proveedores de datos. Los componentes
18
de contenido incluyen la clase DataSet y otras clases de apoyo, como DataTable, DataRow, DataColumn y DataRelation. Estas clases almacenan el contenido real de un intercambio de datos. Los componentes proveedores de datos ayudan a actualizar y recuperar los datos. Los desarrolladores pueden utilizar los objetos Connection, Command y DataReader para manipular directamente los datos. Del mismo modo, utilizan la clase DataAdapter como conducto para mover los datos entre el almacén de datos y los componentes de contenido. Estos datos pueden ser filas reales de una base de datos o cualquier otra forma de datos, como un archivo XML o una hoja de cálculo de Excel (Thai, 2003).
Sin embargo, no todo lo que aporta ADO.NET y su modelo de objetos son ventajas, pues seguía existiendo una desconexión entre la aplicación y la base de datos.
Los desarrolladores pasaban demasiado tiempo tratando de ponerse al día con los cambios que se hacían en la base de datos. Cualquier cambio en el esquema de una tabla o procedimiento almacenado podría romper la aplicación. Por ejemplo, si se realiza una consulta SELECT a la base de datos y uno de los parámetros que se selecciona no existe o no está bien escrito, el código compila perfectamente y solo da error a la hora de ejecutarlo. Esto hace que los desarrolladores dediquen demasiado tiempo a preocuparse por cosas que no deberían cuando se trata de la parte de la base de datos.
Ellos deberían de preocuparse por el desarrollo de la aplicación y no en si una tabla, un procedimiento almacenado, una relación o algún objeto de la base de datos cambia.
Lo que se necesitaba era un modelo en el que la base de datos, la aplicación y los datos se movieran juntos. Esto es exactamente lo que resuelve uno de los principales frameworks de ADO.NET, el Entity Framework (EF). Entity Framework es un modelo conceptual que trabaja con bases de datos y aplicaciones eliminando la brecha entre los datos y las aplicaciones (y los lenguajes de aplicación) con la que los desarrolladores normalmente tienen que lidiar cuando trabajan con el objeto DataReader y otras tecnologías de acceso a datos (Klein, 2010).
Para entender Entity Framework debemos saber lo que es un ORM. ORM es un acrónimo de Object-Relational Mapping o mapeo objeto/relacional. Es pocas palabras, un marco ORM se utiliza para dar persistencia a los objetos del modelo en una base de datos relacional y recuperarlos. Utiliza información de metadatos para interactuar con la base de datos. De este modo, el código de la capa de datos no sabe nada de la estructura de la base de datos por lo que la herramienta ORM se convierte en un middleware que oculta la complejidad.
El corazón de ORM es el mapeo que es lo que une el mundo de los objetos y el relacional. Mediante el mapeo se expresa como una clase y sus propiedades están relacionadas con una o más tablas de la base de datos. Esta información es utilizada por el motor de la herramienta ORM para construir dinámicamente el código SQL que
19
recupera los datos y los transforma en objetos. Del mismo modo, al rastrear los cambios en las propiedades de los objetos, se pueden enviar actualizaciones a la base de datos.
La información de mapeo se expresa generalmente como un archivo XML (Mostarda, 2011).
Como su nombre indica, el Entity Framework permite trabajar directamente con entidades que representan su propio esquema sin tener que lidiar con los matices de los objetos DataReader y DataSet. Algunos desarrolladores que han trabajado directamente con este framework lo comparan con otros mapeadores relacionales y tratan de clasificarlo como una mapeador relacional de objetos, sin embargo, esta clasificación no es del todo correcta. Entity framework tiene capacidades de mapeo relacional, pero va más allá, las capacidades de ORM que tiene están implementadas de forma muy diferente a la de otros productos ORM (Klein, 2010).
Algunas de las ventajas que aporta la utilización de Entity Framework para el acceso a datos en .NET Framework con respecto a otros ORM son (Mostarda, 2011):
• Está implementado en el propio .NET Framework: Microsoft da soporte completo a Entity Framework y garantiza corrección de bugs, documentación y mejoras.
• Está integrado en Visual Studio: Al instalar Visual Studio dispones de un asistente y un diseñador para gestionar la fase de mapeo de forma visual, sin preocuparte por los detalles de implementación.
• Cada versión soluciona muchos de los problemas de las versiones anteriores:
Microsoft escucha los comentarios de la comunidad y desde el lanzamiento de la versión 1.0 ha contratado a expertos para mejorar Entity Framework.
• Es independiente del tipo de base de datos que utilices: La capa de persistencia utiliza la API de Entity Framework para interactuar con la base de datos. Entity Framework se encarga de traducir las llamadas a los métodos en sentencias SQL que sean entendidas por la base de datos.
• Utiliza LINQ como lenguaje de consultas: Language INtegrated Query (LINQ) es una funcionalidad introducida en Visual Studio 2008 que ofrece una nueva forma de interactuar con datos de todo tipo. Proporciona herramientas que facilitan la creación de consultas utilizando menos código. Además, las consultas resultantes suelen ser más fáciles de entender que las obtenidas mediante otras técnicas (Mueller, 2008). En Entity Framework se pueden expresar las consultas utilizando LINQ y el propio framework se encarga de traducir la consulta en código SQL.
• Es recomendado por Microsoft para el acceso a datos: Microsoft asegura que el futuro del acceso a los datos para la plataforma .NET es Entity Framework. Por eso, la empresa trabaja tanto para que sea tan potente.
20
Windows Forms
La nueva interfaz de programación introducida con .NET para escribir aplicaciones Windows con interfaz gráfica de usuario es Windows Forms. Ésta no solo sustituye a todos los antiguos modelos de programación sino también al paquete Forms utilizado en VB 6.0 y anteriores. Windows Forms combina las mejores características de todos estos modelos, y presenta el futuro a largo plazo de Windows (Griffiths, 2003).
Usado junto a Visual Studio .NET, la tecnología Windows Forms permite aplicar técnicas de desarrollo rápido de aplicaciones para crear aplicaciones Windows. Basta con arrastrar y soltar controles en el formulario, hacer doble click en un control y escribir el código para responder al evento asociado. En resumen, las técnicas de desarrollo rápido de aplicaciones VB.NET ahora se hacen realidad para todos los lenguajes .NET (Liberty, 2003).
Windows Forms proporciona un modelo de programación unificado para el desarrollo de aplicaciones estándar en Windows. Es similar a la API nativa de Windows en cuanto a nivel de abstracción, sin embargo, es mucho más completa y potente. En lugar de depender de funciones como la API nativa de Windows, Windows Forms proporciona una jerarquía de clases. En lugar de llamar a la función CreateWindow para cualquier tipo de widgets de interfaz de usuario, se crea el tipo concreto de control de interfaz de usuario, por ejemplo, un botón, utilizando la clase apropiada. Aunque existen otros frameworks que ya ofrecen jerarquía de clases, el aspecto independiente del lenguaje de este nuevo framework es lo que le aporta una gran ventaja frente al resto.
Cualquier lenguaje .NET puede utilizar esta colección de clases que conforma el modelo de objetos de Windows Forms (Thai, 2003).
2.1.2 Mono/Xamarin
Mono es un proyecto de código abierto patrocinado por Xamarin para crear una implementación estándar ECMA de la infraestructura de lenguaje común (Common Language Infrastructure o CLI) de .NET, un compilador de C# y un desarrollo en abierto.
La infraestructura de lenguaje común es una especificación abierta y un estándar técnico desarrollado originalmente por Microsoft y estandarizado por ISO (ISO, 2012) y ECMA International («ECMA-335», 2012) que describe el código ejecutable y un entorno de ejecución que permite utilizar múltiples lenguajes de alto nivel en diferentes plataformas sin tener que reescribirlos para arquitecturas específicas.
El objetivo del proyecto Mono era proporcionar una implementación libre del .NET Framework de Microsoft ofreciendo herramientas de desarrollo, como un compilador gratuito de C#, y un conjunto de clases para ayudar al programador a portar rápidamente las aplicaciones .NET a Mono. El proyecto Mono fue iniciado por Ximian en 2001 y la versión 1.0 se publicó en 2004 (McClure, 2012; Schönig, 2004).
21
Mono está formado por varios componentes (Schönig, 2004):
• Compilador de C#: Es el componente principal de Mono. El compilador es auto- hosting, lo que significa que es posible compilar el compilador de C# bajo sí mismo (el compilador puede compilar su propio código fuente). Esto es un hito importante en la evolución y el desarrollo de Mono, ya que el código se ha vuelto mucho más independiente.
• Un compilador Just-In-Time (JIT) para el CLR.
• Un compilador Ahead of Time (AOT): Permite a Mono precompilar ensamblajes para minimizar el tiempo JIT, reducir el uso de memoria en tiempo de ejecución y aumentar la compartición de código entre múltiples aplicaciones Mono en ejecución.
• Clases y módulos: El marco de trabajo de Mono proporciona un rico conjunto de clases. Microsoft propuso la estructura de estas clases y el proyecto Mono ha intentado cumplir esta propuesta. Es importante mencionar que las clases propuestas por Microsoft forman parte del estándar ECMA.
En 2016, Microsoft adquiere Xamarin con el propósito de crear un descendiente del proyecto Mono que adapte .NET a los sistemas operativos iOS y Android con soporte para Windows Phone (Hermes, 2015; Microsoft to Acquire Xamarin and Empower More Developers to Build Apps on Any Device, 2016). Este descendiente tomaría el nombre que tenía la empresa, Xamarin.
Xamarin es una plataforma de código abierto utilizada para crear aplicaciones de alto rendimiento para Android, iOS y Windows con .NET. Consiste en una capa de abstracción que se encarga de gestionar la comunicación del código compartido con el código de la plataforma a la que va dirigido. Además, se ejecuta en un entorno gestionado que proporciona algunos servicios como la asignación de memoria y la recolección de basura. (What Is Xamarin?, 2021).
Fundamentalmente, Xamarin proporciona un conjunto de envolturas .NET en torno a las APIs nativas del sistema operativo basadas en Mono. Esto proporciona un marco .NET para Android, iOS, Mac y Windows, con bibliotecas y un compilador de C#
para cada plataforma. Esto significa que puedes escribir aplicaciones en C# que se dirijan a cada plataforma de forma nativa y, como utilizas un único lenguaje, puedes abstraer fácilmente toda la lógica (todo lo que no interactúa con el dispositivo directamente) en un conjunto de bibliotecas que pueden compartirse entre plataformas (Bennet, 2018).
La plataforma Xamarin incluye los siguientes productos (ver Figura 6) (Panigrahy, 2015):
• Xamarin.iOS: También conocido como MonoTouch. Se utiliza para crear aplicaciones nativas de iOS utilizando C# y .NET.
22
• Xamarin.Android: También conocido como Mono para Android o más formalmente como MonoDroid. Se utiliza para crear aplicaciones nativas de Android utilizando C# y .NET.
• Xamarin.Forms. Tanto en Xamarin.Android como en Xamarin.iOS, no se puede crear una aplicación multiplataforma pura. La parte de la aplicación que es independiente de la plataforma puede aislarse y reutilizarse en toda la plataforma. Sin embargo, sigue siendo necesario escribir código específico de la plataforma para diseñar la interfaz de la aplicación. Esto es lo que resuelve Xamarin.Forms ya que permite escribir el código de la interfaz de usuario que puede compilarse para iPhone, Android y Windows Phone.
• Xamarin.Mac: También conocido como Mono para Mac. Permite el desarrollo nativo de aplicaciones para Mac utilizando C# y .NET.
• Xamarin.Windows: También conocido como Mono para Windows. Permite desarrollar aplicaciones nativas para Windows utilizando C# y .NET.
Figura 6
Componentes de Xamarin
2.1.3 .NET Core
Hasta hace relativamente poco, si se quería diseñar una aplicación que funcionase en todas las plataformas (Android, iOS, Windows, macOS o Linux), los costes de implementación eran muy grandes puesto que se necesitaba a un equipo de desarrolladores por cada plataforma. Además, los diferentes lenguajes y plataformas utilizados en cada arquitectura dificultaban la integración y mantenimiento de la aplicación. Fue entonces cuando surgió la idea de utilizar el mismo código con las
23
mismas bibliotecas para construir aplicaciones, webs y servicios que funcionasen en cualquier plataforma, pudiendo así reducir costes, tanto en el desarrollo como en el mantenimiento, y asegurar una mayor integración. (Metzgar, 2018).
Esto es lo que consigue .NET Core. En junio de 2016, Microsoft anuncia el lanzamiento de la versión 1.0 de .NET Core, un nuevo y revolucionario framework para los desarrolladores de .NET de todo el mundo. Este nuevo framework se lanzó simultáneamente para Windows, macOS y Linux y se basa en C# y en el .NET Framework.
Este framework, sumado a la adquisición de Xamarin a principios de 2016, permitía a los desarrolladores de .NET programar para cualquier plataforma. La versión inicial incluía el entorno de ejecución de .NET Core, ASP.NET Core y Entity Framework Core. Desde entonces ha habido 8 versiones hasta llegar a la versión 6 que tenemos en la actualidad.
Además de las capacidades de despliegue entre las plataformas, se introdujo otro cambio muy significativo. La plataforma .NET Core y sus frameworks son completamente código abierto. No solo se puede ver y jugar con el código, sino que son proyectos de código abierto en toda regla. Se aceptan pull requests y, de hecho, se esperan. La comunidad de desarrolladores ha hecho importantes aportaciones, con más de 10.000 desarrolladores que han contribuido a la versión inicial de .NET Core. Lo que era un equipo relativamente pequeño de desarrolladores de Microsoft que construían .NET y los frameworks relacionados, ahora es una comunidad muy amplia que puede aportar funcionalidades adicionales, mejoras de rendimiento y corrección de errores (Troelsen, 2017).
Funcionar en otros sistemas operativos aparte de Windows era un objetivo bastante elevado, pero no era el único objetivo que perseguía .NET Core. Los objetivos de .NET Core son (Troelsen, 2017):
• Soporte multiplataforma: .NET Core puede ejecutarse en Windows, Linux y macOs. Las aplicaciones de .NET Core pueden crearse para todas las plataformas utilizando Visual Studio Code o Visual Studio para Mac. Además, con la compra de Xamarin por parte de Microsoft a principios de 2016, se añaden iOS y Android a las plataformas de implementación compatibles.
• Rendimiento: El rendimiento de .NET Core está cerca de la cima de todos los gráficos de rendimiento relevantes y cada versión trae mejoras adicionales.
• Bibliotecas de clases portátiles utilizables en todos los entornos de ejecución de .NET: .NET Core introdujo .NET Standard, una especificación formal para establecer uniformidad en el comportamiento de los entornos de ejecución de .NET. Hablaremos más en detalle de .NET Standard más adelante.
• Despliegue portátil e independiente: Las aplicaciones de .NET Core pueden desplegarse junto con el framework o utilizando la instalación de .NET Core.
24
• Compatibilidad total con la línea de comandos: .NET Core se centra en la compatibilidad total con la línea de comandos como objetivo principal.
• Código abierto: Como he mencionado anteriormente, .NET Core y su documentación son completamente código abierto, con pull requests de la comunidad de desarrolladores de todo el mundo.
• Interoperabilidad con todo .NET Framework: La versión 2.0 de .NET Core permite hacer referencias a las bibliotecas de .NET Framework.
Aunque pueda parecer que .NET Core surgió para sustituir por completo a .NET Framework, la realidad es que ambos coexisten. .NET Framework es y seguirá siendo el framework que se utilizará al escribir aplicaciones de escritorios para Windows. De hecho, es posible que el código de .NET Framework y el de .NET Core convivan en la misma solución. Hay APIs de .NET implementadas tanto en .NET Core como en .NET Framework. Al mismo tiempo, tanto .NET Core como .NET Framework tiene APIs y capacidades que el otro no tiene. Por ejemplo, .NET Framework tiene varios frameworks de interfaz gráfica de usuario y API específicas de Windows que no están presentes en .NET Core. Asimismo, .NET Core tiene capacidades y API multiplataforma de las que carece .NET Framework (Carter, 2016).
.NET Core está compuesto por cuatro partes (Troelsen, 2017):
• El entorno de ejecución (CoreCLR): Es la biblioteca base de .NET Core. Incluye el recolector de basura, el compilador JIT, los tipos básicos de .NET y muchas clases de bajo nivel. El entorno de ejecución proporciona el puente entre las librerías del framework .NET Core (CoreFX) y los sistemas operativos subyacentes. Solo se incluyen los tipos que tienen una fuerte dependencia con el funcionamiento interno del entorno de ejecución. La mayor parte de la biblioteca se implementa como paquetes NuGet independientes.
• Un conjunto de librerías (CoreFX): Este es el conjunto de librerías de .NET Core e incluye clases para colecciones, sistemas de archivos, consola, XML, async y muchos otros elementos básicos. Estas librerías se basan en CoreCLR y proporcionan los puntos de interfaz para otros frameworks en el entorno de ejecución. Juntos, CoreCLR y CoreFX componen .NET Core.
• Herramientas del SDK y el host de aplicaciones dotnet: Las herramientas del SDK incluyen la interfaz de línea de comandos (CLI) de .NET, que se utiliza para crear aplicaciones y bibliotecas de .NET Core. El host de aplicaciones dotnet es el controlador general para ejecutar comandos de la CLI, incluidas las aplicaciones .NET Core.
• Compiladores: La plataforma de compiladores .NET proporciona compiladores de código abierto de C# y Visual Basic con APIs completas para el análisis del
25
código. C# es el lenguaje principal y se admite en todos los frameworks de .NET Core.
2.1.3.1 .NET Standard
Como he mencionado anteriormente, uno de los objetivos de .NET Core era conseguir una estandarización para que todas las implementaciones de .NET pudieran compartir las mismas bibliotecas. Esta estandarización recibe el nombre de .NET Standard y su arquitectura puede verse en la Figura 7 (Metzgar, 2018).
Figura 7
Arquitectura de .NET Standard
.NET Estándar es una especificación formal para las API de .NET que está
disponible en todos los entornos de ejecución de .NET. Con ello se pretende establecer una mayor uniformidad en el ecosistema. Las ventajas principales que aporta .NET Standard a la plataforma .NET son (Troelsen, 2017):
• Define un conjunto uniforme de APIs de bibliotecas de clases base para todas las implementaciones de .NET.
• Permite a los desarrolladores crear bibliotecas portátiles que pueden utilizarse en todas las implementaciones de .NET.
• Reduce o elimina la compilación condicional de recursos compartidos.
2.1.3.2 ASP.NET Core
ASP.NET Core es la evolución de ASP.NET lanzada en 2016 con .NET Core. Las últimas versiones de ASP.NET se han centrado en la alta productividad de los
26
desarrolladores y han priorizando la compatibilidad con versiones anteriores de ASP.NET. ASP.NET Core se aparta de esta tendencia e introduce importantes cambios en la arquitectura que replantea la forma en la que se diseña y se construye la web.
ASP.NET Core hereda de ASP.NET y muchas de sus características se han mantenido; sin embargo, ASP.NET Core es un nuevo framework que reescribe tanto el framework web como la plataforma subyacente.
El desarrollo de ASP.NET Core estuvo motivado por cuatro objetivos principales:
• Ejecutarse y desarrollarse en varias plataformas.
• Tener una arquitectura modular que facilite el mantenimiento.
• Desarrollarse completamente como software de código abierto.
• Ser aplicable a las tendencias actuales de desarrollo web, como las aplicaciones del lado del cliente y el despliegue de entorno en la nube.
Para conseguir todos estos objetivos, Microsoft necesitaba una plataforma que pudiera proporcionar bibliotecas para crear objetos básicos como listas o diccionarios y realizar, por ejemplo, operaciones con archivos. Hasta el momento, el desarrollo de ASP.NET siempre se había centrado en Windows, puesto que estaba basado en un framework que solo podía ejecutarse en ese sistema operativo, .NET Framework. Para ASP.NET Core, Microsoft creó un framework que se ejecuta en Windows, Linux y macOS llamado .NET Core (ver Figura 8).
Figura 8
Imagen comparativa entre .NET Core y .NET Framework
Sólo con .NET Core es posible crear aplicaciones de consola que se ejecuten en varias plataformas. Microsoft creó ASP.NET Core para que fuera una capa adicional sobre las aplicaciones de consola que añadía nuevas bibliotecas para permitir la conversión a aplicaciones web.
27
ASP.NET Core proporciona un framework web generalizado que puede utilizarse en una gran variedad de aplicaciones como sitios de comercio electrónicos, basados en contenido y grandes aplicaciones de n niveles.
Al añadir un servidor web ASP.NET Core a una aplicación .NET Core, la aplicación puede ejecutarse como aplicación web. ASP.NET Core se compone de muchas librerías entre las que se puede elegir para dotar a la aplicación de diferentes características.
Algunas son comunes y aparecen prácticamente en todas las aplicaciones que se crean, como las que se utilizan para leer archivos de configuración o para realizar registros.
Otras se basan en estas capacidades básicas para proporcionar funcionalidad específica, como el inicio de sesión de terceros a través de Facebook o Google.
La mayoría de las librerías que se utilizan en ASP. NET Core se pueden encontrar en GitHub (ASP.NET, s. f.), en los repositorios de la organización Microsoft .NET Core.
Ahí se pueden encontrar las librerías principales, como el servidor web Kestrel y las librerías de registro, así como muchas más librerías como las de autentificación de terceros (Lock, 2018).
Con la llegada de .NET Core 3.0, se añadió un nuevo framework a ASP.NET que permite interactividad del lado del cliente, este framework es Blazor. Se divide en tres partes: Blazor, Blazor Server y Blazor WebAssembly.
Desde el lado del cliente, Blazor es un framework para la creación de interfaces de usuario web interactivas. Permite:
• Utilizar C# para la creación de interfaces interactivas en lugar de Javascript.
• Renderizar la interfaz de usuario utilizando HTML y CSS permitiendo una gran compatibilidad con los navegadores.
• Compartir la lógica de la aplicación del lado cliente y lado servidor escrita en .NET.
• Integrarse con plataformas de alojamiento modernas, como Docker.
• Construir aplicaciones híbridas de móviles y escritorio.
Las aplicaciones de Blazor se basan en componentes. Un componente en Blazor es un elemento de la interfaz, como un diálogo o un formulario de entrada de datos.
Estos componentes suelen estar escritos utilizando el marcado Razor, el cual combina HTML con código C# con el fin de aumentar la productividad del desarrollador.
Del lado del servidor, Blazor Server proporciona soporte para alojar componentes Razor en una aplicación ASP.NET Core. El entorno de ejecución permanece en el servidor y se encarga de:
• La ejecución del código C# de la aplicación.
• El envío de eventos de la interfaz al servidor.
