miércoles, 26 de junio de 2013

Configuración de Variables de Entorno JAVA_HOME y PATH

Introducción


Esta es un tema mas bien básico pero que no esta del todo bien documentado así que pongo mi aporte a beginners: El JDK (Java Development Kit) requiere por parte de las herramientas que lo usan (por ejemplo, ECLIPSE, MAVEN, GRAILS, etc) que se encuentren disponibles y bien configuradas dos variables de entorno: JAVA_HOME y PATH. A continuación se muestra la configuración paso a paso bajo Windows XP.



Configuración de Variables de Entorno JAVA_HOME y PATH


Primero que nada, debemos ir a Mi PC, presionar botón derecho y en el menú contextual seleccionar Propiedades:

Se presentara la pantalla de Propiedades del sistema; esta es una ventana con varias lenguetas. Seleccionamos la lengueta llamada Opciones avanzadas. Allí seleccionamos Variables de entorno como indica la siguiente imagen:


Se presenta la ventana de Variables de entorno, donde configuraremos las mismas. Para ingresar una nueva variable de entorno, En la misma, en la sección Variables del sistema seleccionamos Nueva:


En la nueva ventana, ingresaremos en el campo Nombre de variable, el texto JAVA_HOME, y en el campo Valor de variable, ingresaremos el path a donde tenemos instalado el JDK. En mi caso lo tengo enC:\Archivos de programa\Java\jdk1.7.0_09\; usted verifique el path de la versión que posea instalado e ingréselo del siguiente modo:



Una vez terminado, presione Aceptar.

Seguidamente, editaremos el valor de la variable Path existente. Identifiquela en la sección Variables del sistema como indica la siguiente imagen:


Selecciónela haciendo doble click sobre la misma. Se presentara una ventana de Modificar la variable del sistema. Vaya al final de la linea y agregue el texto ;%JAVA_HOME%\bin , quedando del siguiente modo:


Presione Aceptar y cierre todas las ventanas.

Para probar el funcionamiento, abra una nueva consola y escriba: java -version. Si todo quedó correctamente configurado, deberá ver un mensaje como el siguiente:


lunes, 11 de junio de 2012

C# IoC – Inyección de Dependencias con Unity 2.0

C# IoC – Inyección de Dependencias con Unity 2.0 | DevNinja's Blog:


En el presente post vamos a realizar una implementación básica del desacoplamiento entre componentes en una arquitectura N-CapasLa inyección de dependencias se usa en aquellas ocasiones en las que deseamos que nuestros componentes trabajen de una manera genérica controlando la ejecución de aquellos específicos y maximizando la coherencia entre ellos, también para simplificar el diseño, la implementación y el mantenimiento de las aplicaciones.
Actualmente existe una variedad de frameworks que nos permiten realizar inyección de dependencias entre ellos Unity que viene incluido en la Enterprise Library para este ejemplo vamos a utilizar EntLib 5.0 la cual incluye Unity 2.0.
Unity es un contenedor de inyección de dependencias ligero y extensible, en pocas palabras Unity no es un framework robusto o pesado. Soporta inyección en el constructor, inyección en propiedades, inyección en llamadas a métodos y contenedores anidados. Unity permite mapear Interfaces hacia clases las que podemos instanciar bajo demanda. Entre las diferentes ventajas que ofrece Unity tenemos:
Proporciona una creación de objetos simplificada en estructuras de objetos con dependencias lo cual simplifica el código de la aplicación.
Incrementamos la flexibilidad al mover la configuración de los componentes al contenedor de inyección de dependencias.
Bien ahora veamos un ejemplo, supongamos que tenemos una aplicación N-Capas donde cargaremos información de una base de datos cualquiera a través de una tecnología de acceso a de datos X, implementando algunos de los patrones de diseño de arquitectura para una aplicación N-Capas  a manera de ejemplo didáctico, vamos a crear un nuevo proyecto en mi caso he optado por una aplicación de consola a la cual le agregaré una referencia Unity que se encuentra entre los ensamblados de la Enterprise Library.
El siguiente paso es crear nuestra implementación del contenedor de Unity para resolver las dependencias, lo que voy a hacer es encapsular los métodos necesarios para dicho fin, al ser un objeto que utilizaré a lo largo de toda la aplicación éste será un aspecto transversal de mi aplicación N-Capas.
Lo que haré en la clase FabricaIoC será registrar todos aquellos tipos los cuales quiero que Unity se encargue de la creación de los específicos, por ejemplo voy a registrar el tipo IRepositorioUsuarios e indicarle a Unity que cuando le pida resolver este tipo el deberá crear una nueva instancia de un objeto CsvRepositorioUsuarios donde dicho objeto implementa los métodos para la gestión de usuarios con una tecnología de acceso a datos específica. De igual manera tambíen aislamos a Unity dado el caso que cambiemos el framework de inyección de dependencias nuestra aplicación sigue funcionando igual.
Código:
1: // -----------------------------------------------------------------------
2: // 
3: // Copyright (c) SCI Software 2011. Todos los derechos reservados.
4: // 
5: // Jhonnys Lopez Celedon
6: // -----------------------------------------------------------------------
7: using Microsoft.Practices.Unity;
8: using SCI.Unity.Aplicacion.ModuloPrincipal;
9: using SCI.Unity.Dominio.ModuloPrincipal.Repositorios;
10: using SCI.Unity.Infraestructura.Datos.Repositorios;
11:
12: namespace SCI.Unity.Infraestructura.Transversales
13: {
14:     /// 
15:     /// Fabrica Singleton para la inyeccion de dependencias con Unity
16:     /// 
17:     public class FabricaIoC
18:     {
19:         private static readonly FabricaIoC _contenedor = new FabricaIoC ();
20:         private readonly IUnityContainer _unityContainer;
21:
22:         private FabricaIoC()
23:         {
24:             _unityContainer = new UnityContainer ();
25:
26:             // Registrar los tipos utilizados en la aplicacion.
27:
28:             //_unityContainer.RegisterType();
29:             _unityContainer.RegisterType<IRepositorioUsuarios , CsvRepositorioUsuarios >();
30:             _unityContainer.RegisterType<IServicioUsuarios , ServicioUsuarios >();
31:         }
32:
33:         public static FabricaIoC Contenedor
34:         {
35:             get { return _contenedor; }
36:         }
37:
38:         /// 
39:         /// Crear una instancia de un objeto que implemente un tipo TServicio.
40:         /// 
41:         /// name = "TServicio">Tipo de servicio que deseamos resolver
42:         /// 
43:         public TServicio Resolver() where TServicio : class
44:         {
45:             return _unityContainer.Resolve();
46:         }
47:     }
48: }
49:
Lo que logramos con esta implementación sencilla es olvidarnos de como se realizarán las operaciones dentro de mis repositorios en pocas palabras mi aplicación en las capas superiores como Dominio y Aplicación ignoran como se realiza el acceso a los datos, concentrando toda la atención únicamente en que operaciones realizan dichos objetos.
Tambíen tengo un servicio de aplicación al que he llamado ServicioUsuarios el cual implementa el contrato o interfazIServicioUsuarios en el cual a manera de Facade podemos exponer uno mas métodos de nuestro subsistema en una operación más sencilla, tambíen será el encagardo de tomas decisiones como si una operación necesita ir al dominio para ser validada o ir directamente a los orígenes de datos, en fin dicho servicio “depende” de un IRepositorioUsuarios el cual ya tengo registrado en mi contenedor de Unity.
Las operaciones que realizará mi servicio están en el contrato o interfaz IServicioUsuarios:
1: // -----------------------------------------------------------------------
2: // 
3: // Copyright (c) SCI Software 2011. Todos los derechos reservados.
4: // 
5: // Jhonnys Lopez Celedon
6: // -----------------------------------------------------------------------
7: using System.Collections.Generic;
8: using SCI.Unity.Dominio.ModuloPrincipal.Entidades;
9:
10: namespace SCI.Unity.Aplicacion.ModuloPrincipal
11: {
12:     public interface IServicioUsuarios
13:     {
14:         /// 
15:         /// Obtener todos los registros de la tabla Usuarios.
16:         /// 
17:         /// Coleccion de usuarios registrados.
18:         IList <Usuario > Obtener();
19:     }
20: }
21:
La manera de como se realizan estas operaciones se encuentran definidas en la clase ServicioUsuarios:
1: // -----------------------------------------------------------------------
2: // 
3: // Copyright (c) SCI Software 2011. Todos los derechos reservados.
4: // 
5: // Jhonnys Lopez Celedon
6: // -----------------------------------------------------------------------
7: using System.Collections.Generic;
8: using SCI.Unity.Dominio.ModuloPrincipal.Entidades;
9: using SCI.Unity.Dominio.ModuloPrincipal.Repositorios;
10:
11: namespace SCI.Unity.Aplicacion.ModuloPrincipal
12: {
13:     public class ServicioUsuarios : IServicioUsuarios
14:     {
15:         private readonly IRepositorioUsuarios _repositorioUsuarios;
16:
17:         public ServicioUsuarios(IRepositorioUsuarios repositorioUsuarios)
18:         {
19:             _repositorioUsuarios = repositorioUsuarios;
20:         }
21:
22:  #region IServicioUsuarios Members
23:
24:         public IList <Usuario > Obtener()
25:         {
26:             return _repositorioUsuarios.Obtener();
27:         }
28:
29:  #endregion
30:     }
31: }
32:
Una de las grandes ventajas de Unity es que puede resolvernos grafos de dependencias como el que observamos enIServicioUsuarios que para instanciar un objeto ServicioUsuarios necesitamos pasarle como parámetro en el constructor una instancia de un objeto que implemente IRepositorioUsuario lo cual ya hemos registrado en el contenedor Unity de manera tal que el pedir resolver una instancia de nuestro servicio Unity estará en capacidad de resolver completamente todo el grafo de dependencias.
En la práctica sería:
Código:
1: // -----------------------------------------------------------------------
2: // 
3: // Copyright (c) SCI Software 2011. Todos los derechos reservados.
4: // 
5: // Jhonnys Lopez Celedon
6: // -----------------------------------------------------------------------
7: using System;
8: using System.Collections.Generic;
9: using SCI.Unity.Aplicacion.ModuloPrincipal;
10: using SCI.Unity.Dominio.ModuloPrincipal.Entidades;
11: using SCI.Unity.Infraestructura.Transversales;
12:
13: namespace SCI.Unity
14: {
15:     public class Program
16:     {
17:         private static void Main(string [] args)
18:         {
19:             // Declaramos un IServicioUsuarios y le pedimos a nuestra fabrica de inyeccion de dependencias
20:             // que resuelva de menera automatica dicha peticion.
21:             IServicioUsuarios servicioUsuarios = FabricaIoC .Contenedor.Resolver<IServicioUsuarios >();
22:
23:             // Utilizar uno de los metodos contenidos dentro el contrato.
24:             IList <Usuario > usuarios = servicioUsuarios.Obtener();
25:
26:             foreach (var usuario in usuarios)
27:             {
28:                 Console .WriteLine(usuario.Login);
29:             }
30:
31:             Console .ReadKey();
32:         }
33:     }
34: }
35:
Podemos observar que nuestro contenedor realiza correctamente su labor:
La variable servicioUsuarios ahora tiene una instancia de un ServicioUsuarios que a su vez depende de unIRepositorioUsuario:
De manera sencilla Unity ha resuelto el grafo de dependencias. Si bien ahora supongamos que hemos migrado la información a otro motor de base de datos lo que significa que la tecnología de acceso a datos también pudo haber cambiado, pues con ésta técnica podemos implementar una nueva clase que cumpla con el contratoIRepositorioUsuarios con la tecnología de acceso a datos especifica para el nuevo motor de bases de datos y solo tenemos que modificar el contenedor al momento de registrar los tipos y como resolverlos:
Código:
1: // -----------------------------------------------------------------------
2: // 
3: // Copyright (c) SCI Software 2011. Todos los derechos reservados.
4: // 
5: // Jhonnys Lopez Celedon
6: // -----------------------------------------------------------------------
7: using Microsoft.Practices.Unity;
8: using SCI.Unity.Aplicacion.ModuloPrincipal;
9: using SCI.Unity.Dominio.ModuloPrincipal.Repositorios;
10: using SCI.Unity.Infraestructura.Datos.Repositorios;
11:
12: namespace SCI.Unity.Infraestructura.Transversales
13: {
14:     /// 
15:     /// Fabrica Singleton para la inyeccion de dependencias con Unity
16:     /// 
17:     public class FabricaIoC
18:     {
19:         private static readonly FabricaIoC _contenedor = new FabricaIoC ();
20:         private readonly IUnityContainer _unityContainer;
21:
22:         private FabricaIoC()
23:         {
24:             _unityContainer = new UnityContainer ();
25:
26:             // Registrar los tipos utilizados en la aplicacion.
27:
28:             // Especificamente con una nueva tecnologia de acceso a datos.
29:             _unityContainer.RegisterType<IRepositorioUsuarios , XmlRepositorioUsuarios >();
30:             // _unityContainer.RegisterTypeCsvRepositorioUsuarios>();
31:             _unityContainer.RegisterType<IServicioUsuarios , ServicioUsuarios >();
32:         }
33:
34:         public static FabricaIoC Contenedor
35:         {
36:             get { return _contenedor; }
37:         }
38:
39:         /// 
40:         /// Crear una instancia de un objeto que implemente un tipo TServicio.
41:         /// 
42:         /// name = "TServicio">Tipo de servicio que deseamos resolver
43:         /// 
44:         public TServicio Resolver() where TServicio : class
45:         {
46:             return _unityContainer.Resolve();
47:         }
48:     }
49: }
50:
Donde hemos cambiado que instancia de que tipo devolverá nuestro contenedor Unity a momento de pedirle que resuelvaIRepositorioUsuarios, podemos observar que ahora la instancia del repositorio usuarios que tiene el servicio de usuarios implementa XmlRepositorioUsuarios.
Hemos desacoplado la tecnología de acceso a datos en nuestra aplicación por medio de Unity, lo cual en el futuro nos facilitará el mantenimiento de dicha aplicación al momento de reemplazar una tecnología por otra sin que el comportamiento de nuestra aplicación cambie.
Solución:
fuente:
C# IoC – Inyección de Dependencias con Unity 2.0 | DevNinja's Blog

Una introducción a MongoDB

Una introducción a MongoDB:

'via Blog this'