Dominio de aplicacion

Creo que una de las característica más desconocidas de .Net son los dominios de aplicación. Y en la practica lo estamos utilizando constantemente. Se trata de una característica que proporciona una capa de aislamiento dentro de un proceso. Todo lo que en realidad se piensa que es por proceso (variables estáticas, ...) en realidad es por dominio de aplicación.

Esta característica es muy útil para crear:
  • Plugins: pudiendo cargar ensamblados en tiempo de ejecución, sin que este afecte al resto de la aplicación.
  • Seguridad: Nos permite ejecutar conjuntos de código en un nivel de confianza específico.
  • Aislamiento: Puedes ejecutar diferentes versiones de un ensamblado en el mismo proceso.
  • Control de fugas de memoria: Si tenemos un proceso que consume gran cantidad de memoria y el recolector de basura no es capaz de liberarla, una solución es hacer correr el proceso en un dominio de aplicación diferente, y al destruir el dominio de aplicación se liberará toda la memoria que utilizaba.
  • Modificar ensamblados en tiempo de ejecución: Con esta característica es posible modificar los ficheros de ensamblado en tiempo de ejecución.
Un entorno en el que se utilizan los dominios de aplicaciones es en las aplicaciones asp.net, cuando montamos varios sites en el mismo proceso, lo que hace el IIS es crear un dominio de aplicación por cada aplicación asp.net

Para controlar un dominio de aplicación se utiliza la clase AppDomain, la cual nos permite conocer propiedades del dominio actual con AppDomain.CurrentDomain.


AppDomain miDominio = AppDomain.CurrentDomain;

O crear y destruir otros dominios de aplicación.


AppDomain miDominio = AppDomain.CreateDomain("NuevoDominio");
Con las diferentes sobrecargas del método CreateDomain se pueden definir criterios de seguridad, directorio de trabajo del nuevo dominio de aplicación, definir si se puede modificar los ficheros del ensamblado en tiempo de ejecución, ...

Una vez creado el nuevo dominio, lo siguiente que hay que hacer notar es que para comunicarse entre diferentes dominios de aplicación alojados en un mismo proceso hay que utilizar remoting. Por ello definiremos una clase de entrada que herede de MarshalByRefObject. Con un método que nos servirá de punto de entrada.

public class MiControladorDominio : MarshalByRefObject
{
    public void Inicio(int id)
    {
              
    }
}

Ahora tenemos que crear una instancia de nuestra clase controlador en el nuevo dominio.


MiControladorDominio controlador = (MiControladorDominio)miDominio.CreateInstanceAndUnwrap(
                typeof(MiControladorDominio).Assembly.FullName,
                typeof(MiControladorDominio).FullName);

Y ya podemos comunicar los dos dominios de aplicación mediante la instancia de la clase MiControladorDominio llamando al método publico de inicio. Recordando que la comunicación se hace a traves de remoting, con lo que todos los objetos de ida y vuelta serán serializados.

controlador.Inicio(55);

Cuando terminemos de utilizar el nuevo dominio, lo podemos destruir mediante el método Unload, liberando todos los recursos que ha utilizado el nuevo dominio.

AppDomain.Unload(miDominio);
La utilización de dominios de aplicación no es algo muy utilizado, principalmente, por su complejidad. Pero en ocasiones resuelve problemas que de otra manera seria más difícil de solucionar.

Comentarios

Publicar un comentario

Entradas populares de este blog

Certificados de no confianza con Git

Si tienes un servidor Git con un certificado auto firmado, posiblemente de un problema de confianza. Si se produce este error SSL certificate problem: unable to get local issuer certificate al intentar descargar un repositorio de Git, una forma de solucionar el problema es ejecutar el comando. git config --global http.sslVerify false Para devolver a la configuración original. git config --global http.sslVerify true
Leer más

Pruebas unitarias con Entity Framework Core

Las pruebas unitarias contra base de datos siempre son complicadas. Ya que en muchas ocasiones no podemos crear una base de datos vacía para nuestras pruebas. Si utilizamos Entity Framework esta tarea se hace muy sencilla, con este sencillo truco. En la que creamos una base de datos al inicializar el test y la borramos al terminarlo. Para ello deberemos utilizar los métodos EnsureCreated y EnsureDeleted, las cuales crean y borran una base de datos de una forma muy sencilla. [ ClassInitialize ()] public static void InitDataBase( TestContext context) {      using ( var db = new MyDbContext ())      {         db.Database.EnsureCreated();      } } [ ClassCleanup ] public static void DeleteDataBase() {     using ( var db = new MyDbContext ())     {         db.Database.EnsureDeleted();     } }
Leer más

Buenas practicas con Async/Await

Con la aparición de los procesadores con varios núcleos se ha vuelto critico el saber manejar la multitarea. Desde la primera versión del Framework de .Net existe el espacio de nombre System.Threading , el cual se puede considerar un wrappear para acceder a las directivas de sincronización del sistema, acceder al pool de hilos o crear nuestros propios hilos. Posiblemente con System.Threading se puede realizar cualquier tarea. Pero la dificultad de su uso y mantenimiento han invitado a crear otro tipo de librerías más sencillas. Primero se abordo la multitarea de CPU. Con una nueva clase para manejar tareas que es Task , un controlador llamado Parallel y una serie de clases para manejar colecciones de forma asíncrona. Esto nos permite aprovechar los diversos núcleos de los procesador actuales. Permitiendo lanzar tareas en paralelo y sincronizarlas de una forma sencilla. Pero había un escenario que seguia siendo complicado. Y con la aparición de los entornos táctiles se emp
Leer más