Shared Project – PCL – .NET Standard [Shared Code Alternatives] #Xamarin


Un componente clave en el desarrollo de aplicaciones multiplataforma es el poder compartir código entre varios proyectos para las plataformas específicas y, al encontrarnos aprendiendo sobre Xamarin, nos hemos topado que existen tres distintos métodos para compartir el código entre los proyectos multiplataforma:

Proyectos Compartidos | Bibliotecas de Clases Portable | Bibliotecas Estándar de .NET

Proyectos Compartidos

Este tipo de proyecto sirve para organizar el código fuente y usar directivas de compilador #if según sea necesario para administrar los requisitos específicos de la plataforma.

Biblioteca de Clases Portables

Con esta modalidad se crea como destino la biblioteca de clases portables en las plataformas que se desea admitir y permite utilizar Interfaces que proporcionan la funcionalidad específica de cada plataforma.

Bibliotecas Estándar de .NET

Esta opción funciona de forma similar a la de clases portables, puesto que requiere el uso de interfaces para poder insertar la funcionalidad especifica de la plataforma.

Cabe destacar que el hecho de que se empleen distintos conjuntos de diferentes subcarpetas de la biblioteca de clases base (Base Class Library – BCL) de .NET para las diversas plataformas, hace que se complique aún más, puesto que esto genera un perfil de núcleo de .NET distinto.


Una vez sabiendo lo anterior, seguramente surgen preguntas como: ¿cuál se debe utilizar?, ¿cuál es la diferencia entre cada uno?, ¿cuál se adapta a mis necesidades?, ¿cuál nos permite compartir más código?, etc.

En este apartado abordaremos las diferencias entre cada uno, para poder identificar el más adecuado y así comenzar con el pie derecho el desarrollo de nuestra aplicación.

El objetivo de una estrategia para compartir el código es compatible con la arquitectura que se muestra en el siguiente diagrama, en donde un solo código base puede ser utilizado por diferentes plataformas. 01

Arquitecturas de Código Compartido

Proyectos Compartidos (Shared Projects en inglés)

El enfoque de un Shared Projects (SP) es totalmente distinto a lo que normalmente hacemos como desarrolladores, en donde nuestro código es compilado únicamente en el proyecto donde pertenece, lo cual es particularmente útil (y en varios casos necesario). En los proyectos compartidos solamente tendremos aquellos recursos que queramos compartir entre otros proyectos, entonces se puede visualizar más bien como un repositorio de contenidos. Luego dichos recursos estarán compilados o asociados directamente a aquellos proyectos donde haya referencias al Shared Project en cuestión.

La arquitectura conceptual se muestra en el diagrama siguiente, donde cada proyecto incluye todos los archivos de código fuente compartido: 02

Ventajas

El código compartido se puede bifurcar en función de la plataforma mediante directivas de compilador, por ejemplo: usar #if __ANDROID__.

Permiten compartir código, archivos (assets) y recursos a través de múltiples tipos de proyectos.

Desventajas

Los proyectos compartidos no producen un assembly reutilizable, por lo que solo puede ser consumido dentro de la solución, así como no pueden tener dependencias de bibliotecas de terceros.

Durante la compilación, los archivos se tratan como parte del proyecto que hace referencia y compilados en dicho ensamblado.

Si se desea compartir el código como un ensamblado, a continuación, bibliotecas de clases portables o estándar de .NET son la mejor solución.

Bibliotecas de Clases Portables (Portable Class Library en inglés)

Los PCL nos permiten compartir código entre distintas plataformas de .NET a través de una sola librería (“una sola .dll”). Con ella podemos hacer algo como esto:

03

Cuando se crea un proyecto de biblioteca portable, este está restringido para que funcione en la plataforma concreta para la que se ha creado el archivo DLL resultante. Esto evita tener que escribir un ensamblado para una aplicación de Windows y, a continuación, volver a usarlo en Xamarin.iOS y Xamarin.Android.

Cuando se combinan los PCLs con Nugets, las aplicaciones son incomparables, es por ello que los creadores de los Frameworks y de las librerias (Librarys) continuaran ofreciendo estas, porque saben que cuentan con una baja barrera de adopción, la cual nos permiten brindar una experiencia u operabilidad excepcional a nuestros usuarios finales.

El siguiente diagrama muestra la arquitectura de una aplicación multiplataforma mediante una biblioteca de clases portable para compartir código:

03-01Ventajas

Los proyectos de bibliotecas portables producen una biblioteca .dll reutilizable que pueden tener dependencias de bibliotecas de terceros.

Cuentan con el uso compartido del código de manera centralizada: escribir y probar el código en un proyecto único que puede ser utilizado por otras bibliotecas o aplicaciones.

Los proyectos apuntan a perfiles específicos que soportan un conjunto conocido de clases / características BCL.

Desventajas

No se puede usar las directivas de compilador.

Solo un subconjunto de .NET Framework está disponible para usarse, determinado por el perfil seleccionado, por ejemplo, MonoTouch y Mono para Android (dllImport o System.IO.File).

A menudo los proyectos PCLs requieren esfuerzo arquitectónico adicional para separar el código específico del perfil en sus propias bibliotecas.

Se determina una buena solución, si se tiene previsto compartir el ensamblado resultante con otros desarrolladores, independientemente de hacerlo.

Bibliotecas Estándar de .NET (.NET Standard en inglés)

La biblioteca estándar .NET es una especificación formal de las API de .NET que están pensadas para estar disponibles en todos los entornos de ejecución de .NET.

La finalidad de la biblioteca estándar consiste en establecer una mayor uniformidad en el ecosistema de .NET. Se puede considerar como una representación simplificada de próxima generación de las bibliotecas de clases portables, puesto que es una sola biblioteca con una API uniforme para todas las plataformas. NET, incluido .NET Core.

De forma general, .NET Standard es una especificación de las distintas APIs que .NET en general nos brinda para cada una de las plataformas de ejecución que haya disponibles.

A continuación, podemos observar que el diagrama indica que la arquitectura de una aplicación multiplataforma usando .NET Standard es similar a la de un PCL.

04

.NET estándar es similar a PCL, pero con un modelo más sencillo para la compatibilidad con la plataforma y un mayor número de clases a partir de la BCL. 

Ventajas

Permite compartir código entre varios proyectos.

Las operaciones de refactorización siempre actualización todas las referencias.

Un área de superficie grande de la biblioteca de clases de Base (BCL) de .NET está disponible a perfiles PCL.

Desventajas

No se puede usar las directivas de compilador.

El lanzamiento de Xamarin.Forms 2.3.5 agregó la compatibilidad con .NET Standard

A nivel práctico/código, .NET Standard es un tipo de proyecto más que tenemos disponible en Visual Studio, bajo el esquema de librería de clases. El objetivo de este es reemplazar las librerías de clases portables que estábamos usando con anterioridad.

¿Qué procede entonces?

Entonces, sea cual sea la estrategia de código compartido que elijamos está estará determinada por las plataformas de destino. PCL o .NET Standard son una buena elección para la creación de bibliotecas de código que puede compartirse (especialmente a publicar en NuGet). Los proyectos compartidos funcionan bien para los desarrolladores de aplicaciones que pretende utilizar una gran cantidad de funcionalidad específica de plataformas en sus aplicaciones multiplataforma.

Desde de mi punto de vista sinceramente todo depende del tipo de proyecto, por si se llegara a usar solamente PCL para todo es como si se usara un cañón para matar a una mosca, porque para realizar algunas tareas básicas existen demasiadas limitaciones.

Información extraída de: Microsoft Docs

Anuncios

2 comentarios sobre “Shared Project – PCL – .NET Standard [Shared Code Alternatives] #Xamarin

  1. Hola, me puede ayudar estoy iniciando en xamarin pero cuando copilo las app en mi samsung s7 tiende a demorarse al abrir la app y es un solo hello world, ya lo intentado con shared project y .net standard, se queda hasta 3 a 4 segundos para abrir la pantalla

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s