José Jorge Márquez Gómez

Os dejo una presentación que hice sobre arquitectura MVC, es una explicación muy conceptual y por encima pero lo suficiente a mi entender
para que se entienda dicha arquitectura.
¡Que la disfruteis!

Arquitectura MVC

Bueno, no estoy acostumbrado a contar cosas que me suelan ocurrir, pero es que ultimamente solo vivo para la universidad. No hago nada más que entregar un trabajo por alli, hacer una entrega por allá, joder… esto es demasiado. Pero bueno espero que todo esto de un fruto en el futuro porque la verdá no veo nada de futuro en esto.
Si miramos bien en el mundo de la informática los que triunfan son los que presentan un documento que ni siquiera saben lo que es o bien hacen una presentación en powerpoint que es la repera (y encima no lo han hecho ellos)…. no creo que sea la primera vez que esto ocurre en alguna empresa, ocurre en todas.

El que he me haya decidido a hacer la carrera es meramente porque en este país hay titulitis, si TITULITIS. A lo largo de lo que llevo trabajado (no es mucho, pero lo suficiente para ver las cosas que he visto) me he dado cuenta de que las personas no saben por lo que han estudiado, sencillamentente se preocupan de transmitir lo que han aprendido en su enseñanza… ¿dónde quedaron lo ideales de la curiosidad y la intriga? es decir, por qué las personas no se preocupa ahora de averiguar porqué ocurre tal cosa. Parecemos máquinas aplicando teoremas, algoritmos, ideales aprendidos.

Como dijo Einstein:

Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber.

Esto ya no es así, pues la gente se preocupa de estudiar para encontrar un trabajo (que no está mal por otro lado), pero perdemos mucho. Perdemos los ideales por lo que nuestros antepasados estuvieron sobre la tierra, Albert Einstein, Max Planck, Isaac Newton, Aristóteles… etc.. esto si eran verdaderos pensadores y no lo que tenemos hoy día.

Cuando uno está en la empresa se da cuenta de este tipo de cosas,siendo analista se da cuenta de muchos detalles más de este tipo, jefes que no tienen ni idea de lo que hablan, reuniones que no se le encuentran fin, productos que nuncan se terminan de definir (y encima te dicen que lo definas tu!!!). En fin, y cuando pones un poco de orden y cordura en el asunto te das cuenta de que no sirve de nada, pues lo que manda es la mano “divina”.

Pero todo esto forma parte de la vida… vida que nos ha tocado vivir…

He fusionado el blog de donet y dojava, además de ampliar la temática para poder así ayudar más en el blog. Espero así alimentarlo mucho más.

Un patrón factoría nos sirve para canalizar todas las creaciones de objetos en un solo punto. Esto es útil para un diseño robusto de nuestro sistema y ágil al cambio.

El patrón factoría se puede combinar con el patrón singleton ya que es más cómodo su uso y útil su forma de usar. En este ejemplo pondremos un factoría sin singleton.

Decir que el patrón factoría es del tipo patrones creacionales, que este tipo de patrón abstrae la forma de crear objetos concretos, dando así un soporte para crear objetos de forma abstracta.

Para empezar un patrón factoría debe cumplir:
- Una función o método el cual se encarga de crear objetos de un tipo dado.
- No es obligatorio pero si recomendable que dicha función o método devuelva una abstracción (interfaz o clase abstracta).

Imaginemos que una tienda de pizzas requiere de un software que necesita que tengan una serie de productos (pizzas variadas). Como buenos diseñadores que somos, la creación de objetos de pizzas se podrá hacer desde cualquier parte el proyecto, pero el problema es que hay muchos tipos de pizzas. El crear cada pizza de cada tipo en distintos puntos del programa sería lo primero que pensaríamos, pero… ¿si en vez de eso usamos sentido común y aplicamos el factoría?, esto nos permitiría que dado un nuevo producto o un cambio en alguno de ellos, que solo cambiemos en un solo lugar, teniendo más controlado dicho código. Incluso si os dais cuenta la agilidad al cambio es mucho mayor que ir cambiando todas las posibles apariciones de nuestras pizzas por el código.
Pues bien, el factoría se encargaría de crear todo tipo de pizzas y las ofrecería a todos los posibles puntos del programa.

Nuestro ejemplo sería el siguiente:

- La interfaz IPizza:

    interface IPizza
    {
        void quienSoy();
    }

- Las pizzas concretas:

    public class PizzaBarbacoa: IPizza
    {
        #region Miembros de IPizza

        public void quienSoy()
        {
            Console.WriteLine("Soy una pizza de Barbacoa");
        }

        #endregion
    }

    public class PizzaMargarita: IPizza
    {
        #region Miembros de IPizza

        public void quienSoy()
        {
            Console.WriteLine("Soy una pizza de Margarita");
        }

        #endregion
    }

    public class PizzaPepperoni: IPizza
    {
        #region Miembros de IPizza

        public void quienSoy()
        {
            Console.WriteLine("Soy una pizza de Pepperoni");
        }

        #endregion
    }

- La factoría en cuestión:

    public class PizzaFactory
    {
        public enum tipoPizza
        {
            Pepperoni,Margarita,Barbacoa
        }

        public IPizza getPizza(tipoPizza tipo)
        {
            switch (tipo)
            {
                case tipoPizza.Barbacoa:
                    return new PizzaBarbacoa();
                    break;
                case tipoPizza.Margarita:
                    return new PizzaMargarita();
                    break;
                case tipoPizza.Pepperoni:
                    return new PizzaPepperoni();
                    break;
                default:
                    return new PizzaBarbacoa();
            }
        }
    }

- Un pequeño test:

    public class Test
    {
        public void testPizza()
        {
            //ejemplo no usando factoría
            IPizza pizza1 = new PizzaBarbacoa();
            pizza1.quienSoy();
            IPizza pizza2 = new PizzaMargarita();
            pizza2.quienSoy();
            IPizza pizza3 = new PizzaPepperoni();
            pizza3.quienSoy();
            IPizza pizza4 = new PizzaBarbacoa();
            pizza4.quienSoy();
            IPizza pizza5 = new PizzaMargarita();
            pizza5.quienSoy();

            //ejemplo usando factoría
            PizzaFactory factory = new PizzaFactory();
            IPizza pizza6 = factory.getPizza(PizzaFactory.tipoPizza.Barbacoa);
            pizza6.quienSoy();
            IPizza pizza7 = factory.getPizza(PizzaFactory.tipoPizza.Margarita);
            pizza7.quienSoy();
            IPizza pizza8 = factory.getPizza(PizzaFactory.tipoPizza.Pepperoni);
            pizza8.quienSoy();
        }
    }

Como veis la forma de uso y sus ventajas son mejores. Espero que os sirva!!. Hasta luego!

Bueno hoy os voy a contar un poco como configurar log4net para c#. Pero antes deciros que es log4net.

Log4Net es un framework portado de la librería log4java, el cual te ofrece todas las herramientas posibles para poder hacer un logging, control de errores, monitorización de aplicaciones para todas tus aplicaciones posibles. A mi modo de ver, es el log más bueno que he probado hasta ahora y es bastante fácil de configurar. Ofrece bastantes modos de monitorización e incluso el crearte los tuyos propios. Dicha librería la podeis obtener de http://logging.apache.org/log4net/index.html.

Explicaremos algunos conceptos referentes al log4net.

Log4NET ofrece distintos niveles de monitorización predefinidos como son:

1. Debug: Se suele usar para líneas de debug.
2. Info: Se suele usar para dar información relativa de vuestra aplicación.
3. Warn: Son posibles puntos de ruptura de vuestro software, osea, posibles alertas importantes.
4. Error: Se usa para detectar errores de vuestro software.
5. Fatal: Se usa para detectar posibles errores importantes de software, es decir, que impidan el funcionamiento del mismo por ejemplo.

Estos niveles son los que trae predefinidos log4net, pero se pueden crear niveles personalizados.

Otro punto a destacar son los Appenders, esto no es sino el modo en que los distintos niveles del log4net van a ser monitorizados/logeados, en log4net existen estos entre otros:

1. FileAppender: Logea el nivel definido en la configuración en fichero.
2. RollingFileAppender: Logea el nivel definido en la configuración en un fichero que va rotando dependiendo de su peso.
3. SmtpAppender: Logea el nivel definido en la configuracion y es enviado a un destinatario de correo.

Más adelante en un ejemplo de configuración veréis estos niveles configurados. Para más detalles de todas sus propiedades de los appenders podéis ver la web que tenéis a continuación.

Todos los podéis ver detallados en esta web http://logging.apache.org/log4net/release/config-examples.html.

Comencemos.

El primer paso es descargaros la librería de la web anterior, una vez descargada dicha librería debéis agregarla a las referencias de vuestro proyecto. Seguidamente vamos a configurar el log4net en el fichero de configuración de vuestra aplicación, en caso de una aplicación web será el web.config, en caso de una aplicación consola el app.config, etc…

En el tag “configuration” –> “ConfigSection” –> agregad la siguiente línea:

<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821"/>

A continuación en un tag nuevo que creemos llamado “<log4net>” se configuran allí los appenders. Cada uno tiene su propia configuración en la web anterior se pueden ver todas. Adjunto Ejemplo log4net

Una vez tenemos esto configurado ya podemos hacer uso de nuestro log4net en nuestra aplicación. Un requisito que debe cumplir es que cada clase debe inicializar el log4net en su constructor tal que quede como pone en el siguiente código:

class test
{
private ILog log;
public test()
{
log4net.Config.XmlConfigurator.Configure();
log = LogManager.GetLogger(this.GetType()); //aquí procedemos a inicializar el objeto log.
}

Para hacer uso de nuestro log es simple, solo deberemos llamar a los distintos niveles de alerta que posee a través del objeto log.

Espero que os sirva como inicialización con el log4net.

Saludos!

Bueno, después de mi letargo (siento mucho no postear antes, pero la universidad me tenia tiene agobiado), voy a hablar de algunos patrones de diseño sobre .NET.

Pero antes un poco de “historia”:

Los patrones de diseño sirven para varias cosas, (extraído de wikipedia):
* Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
* Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
* Formalizar un vocabulario común entre diseñadores.
* Estandarizar el modo en que se realiza el diseño.
* Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Y como bien dicen en wikipedia no pretenden imponer nada y abusar de los mismos puede ser un error.

Bien veamos algunos patrones en .NET.

Patron Singular (Singleton):
Este patrón nos asegura que solo haya una instancia por clase evitando así consumos excesivos de recursos o accesos inconsistentes. Sus usos pueden ser varios, entre ellos el acceso a configuraciones globales, de logging, etc..
El esquema general sería:

Public Class PatronSingular
 Private Shared instanciaUnica As PatronSingular

 Private Sub New()
 'constructor privado para generar la instancia la propia clase
 End Sub

 Public Shared Function getInstance() As PatronSingular
 'controlamos la creacion de objetos desde la propia clase.
 If instanciaUnica Is Nothing Then
 instanciaUnica = New PatronSingular()
 End If
 Return instanciaUnica
 End Function
End Class

Un patrón Singleton su constructor debe ser privado para que sea la clase la controle su propia creación y sea responsable de la misma. Debemos crear un método, que normalmente se llama “getInstance()” que nos devuelve dicha instancia de clase para su uso.

Patrón decorador (Decorator):
Nos hace de “envoltura” de objetos, en una definición formal lo que hace es definir una funcionalidad a los objetos que se hereden de este y asignarles así una responsabilidad. En resumen, nos da la posibilidad de generar clases con funciones que se generen dinámicamente. Hay muchos ejemplos de este tipo en .NET, entre ellos los de manejo de ficheros (FileStream su decorador es Stream). En comparación con JAVA, esto correspondería a las clases abstractas. Ejemplo:

Public MustInherit Class PatronDecorador
 'Ofrece una funcionalidad base para todos sus hijos pero
 'que funcionen de manera distinta:
 'por ejemplo:
 'Chocolate tendrá un precio y una descripción distinta que
 'la mantequilla, pero ambos se pueden derretir!.
 Public MustOverride Function Precio() As Double
 Public MustOverride Function Descripcion() As Double

 Public Function Derretir() As Boolean
 'Derretir
 Return True
 End Function

 'Obliga que sus hijos se deban instanciar de una forma concreta
 Public Sub New(ByVal ModificadorAcceso As String)
 End Sub
End Class

Public Class Chocolate
 Inherits PatronDecorador

 Public Overrides Function Descripcion() As Double
 Return "Chocolate"
 End Function

 Public Overrides Function Precio() As Double
 Return 10.2
 End Function

 Public Sub New(ByVal param As String)
 MyBase.New(param)
 End Sub
End Class

Public Class Mantequilla
 Inherits PatronDecorador

 Public Overrides Function Descripcion() As Double
 Return "Mantequilla"
 End Function

 Public Overrides Function Precio() As Double
 Return 3.6
 End Function

 Public Sub New(ByVal param As String)
 MyBase.New(param)
 End Sub
End Class

Bueno, espero escribir más a menudo, pero el tiempo me tiene ahogado!!,  en otro artículo intentaré describir los patrones estrategia, adaptadores y observadores. Saludos!!!

Bueno, para comenzar diremos que los estándares admitidos por .NET para los idiomas los podéis ver en la MSDN http://msdn.microsoft.com/es-es/library/system.globalization.cultureinfo(VS.80).aspx, deciros tambíen que la cultura en un WebForm se establece automáticamente por cada sesión de usuario que se inice en el web, dependiendo del idioma que esté configurado en el navegador del cliente.

Ahora nos surge el problema de forzar el idioma a escoger, bien porque nuestra página permite otros idiomas o bien por necesidad intrínseca del funcionamiento de nuestra página. Teniendo en cuenta los estándares mencionados arriba, podemos variar la cultura de nuestra página de la siguiente manera:

Thread.CurrentThread.CurrentCulture = New CultureInfo("es-ES")
Thread.CurrentThread.CurrentUICulture = New CultureInfo("es-ES")

Bien, explico un poco esto, en las lineas podemos ver que vamos a variar la cultura actual del sitio web y la cultura de la interfaz, esto se hace con CurrentCulture y CurrentUICulture, en primera instancia debemos de establecer la cultura principal del programa a través del hilo principal de ejecución del mismo, esto se hace cogiendo este hilo principal, Thread.CurrentThread, y estableciendo la cultura en ese instante.

Otro problema que nos encontramos es que en el momento de cambiar la cultura, podríamos establecer esta cultura en el hilo en el instante que nos apetezca, pero ocurre que la página Webform ya ha establecido su cultura previamente a nosotros cambiarla, ya que hay un procedimiento en un nivel superior de la jerarquia de clases de la Webform que ha hecho este trabajo y ha escogido el idioma previamente. Pues bien, para solventar este problema y que el cambio de idioma lo veamos reflejado en nuestra web en el momento del cambio, hay otra solución, sobrecargar el método “InitializeCulture” de la clase padre “System.Web.UI.Page” de nuestro WebForm, y ahí colocar el código del cambio de cultura, ya que este procedimiento es el que se encarga de inicializar la cultura de nuestra página antes de ser mostrada en el cliente. Esto quedaría así:

    Protected Overrides Sub InitializeCulture()
        Thread.CurrentThread.CurrentCulture = New CultureInfo("es-ES")
        Thread.CurrentThread.CurrentUICulture = New CultureInfo("es-ES")
    End Sub

Bueno, y esto abre a la imaginación tanto como os apetezca, por cierto en el valor “es-ES” se pueden poner todos los valores aceptados por este método descrito en la web de arriba. Así que ya podeís cambiar el idioma de vuestra web “cuando os apetezca” .

Saludos!

Bien, en este post voy a intentar explicar que es el CLR de NET Framework, para mí, y para mi opinión personal el CLR es una maquina virtual al mismo estilo que JVM para java, es la máquina virtual donde se ejecuta el bytecode de los ensambladores generados en .NET. Los compiladores de lenguajes .NET se encargan de compilar el código a bytecode MSIL (Microsoft Intermediate Languaje), que es el interpretado por el CLR.

El CLR compila por bloques el código MSIL en tiempo real, es decir, conforme se vayan usando las funcionalidades del ensamblado, el CLR generará un código nativo que es el que finalmente se ejecutará en la máquinal, así se intenta abstraer el código creado en la máquina bajo cualquiera de los lenguajes usados en .NET del código máquina.

CLR se divide por capas en su núcleo, para dar más interoperabilidad con el sistema y los desarrolladores. Estos son:
- Niveles de seguridad.
- Manejo de excepciones.
- Administración de hilos.
- Administración de memoria.
- Recolector de basura (GAC)

Destacar que a pesar que es una “maquina virtual” el CLR solo se ejecuta en entornos Windows.

Adjunto una pequeña imagen explicativa del CLR (Autor: Leif Arne Storset, Fuente: Wikipedia):

Es un post pequeño pero creo que explicativo a pequeños rasgos. Saludos!

Deciros que la nomenclatura using es muy útil usarla cuando usamos recursos que debemos liberar forzosamente (acceso a fichero, aperturas de registro en bd’s, manipulación de imágenes…etc) para no tener problemas despúes.

Como nomenclatura de visual studio es muy usada para el acceso a ficheros, pero es posible usarse con cualquier clase que implemente la interfaz IDisposable, asegurándonos que la clase usada en el estamento using liberará “SI o SI” (como dice un presidente de un club de futbol ) los recursos que esté usando, dé error en el bloque de código o no, ya que es el Garbage Collector del visual studio el que se encarga de llamar a el método dispose de la clase que implementa la interfaz.

Para este ejemplo usaremos el acceso a un fichero.

El ejemplo es sencillo, ya que lo único que debemos hacer es usar la nomenclatura de este modo:

Using fich As New FileStream("C:\pruebas.txt", FileMode.Open)
       'CODIGO A ESCRIBIR PARA MANEJAR EL FICHERO
End Using

De este modo nos estamos asegurando que  el fichero pruebas.txt será liberado cuando termine el bloque using, sin provocar problemas en posteriores accesos al fichero.

Hay casos, como por ejemplo, el acceso a datos que al declarar el bloque nos obliga a abrir dicha conexión dentro del bloque, con esto quiero decir, que no por crear el bloque using ya damos por hecho que el recurso se abre y se cerrará solo (esto último sí es cierto). Lo que damos por hecho es que en el caso del ejemplo anterior si se abrirá el archivo porque la clase FileStream en su constructor ya abre el recurso, pero en el caso de una conexion de datos el constructor de dicho conector de datos no abre la conexion en su constructor, con lo cual debemos abrirlo una vez asignado el recurso.

Ejemplo:

'ESTA DECLARACIÓN NO IMPLICA LA APERTURA DE LA CONEXIÓN SOLO LA INICIALIZACION DEL OBJETO
Using conn As New SqlConnection("CadenaConexion")
           conn.Open() 'Esto si nos asegura su apertura, ya el bloque using se encargará de liberarlo (cerrar la conexión)
          'CODIGO A ESCRIBIR
End Using

Resumiendo,

Lo que si nos aseguramos con un bloque using es la liberación de recursos, pero no la apertura de esos recursos, esto dependerá de la clase usada en el using.

Yo estuve un tiempo buscando como registrar una DLL en el COM para la interoperabilidad con ASP 3.0, PHP, etc.. bueno despues de buscar y buscar, investigar, romperme los ojos… etc… era más simple de lo que pensaba. Para poder registrar una dll en el COM de windows primero debemos definir la clase como visible desde el COM y definirle una key o firma del ensamblado. Se hace de la siguiente manera:

1.- Indicamos al proyecto que sea visible desde el COM.

2.- Creamos la key del proyecto.

Hay que tener en cuenta que a la hora de compilar el ensamblado debemos hacer funciones (procedimientos) que sean “entendibles” por cualquier lenguaje de programación no .net, esto es, usar si se puede, funciones, procedimientos, propiedades, etc.. que devuelvan tipos de datos nativos, así será más facil entender por ASP3.0 por ejemplo, php o cualquier otro. Si un momento dado tu ensamblado posee funciones no compatibles con COM el registro del COM avisará cuando se registre en la máquina (solo si necesita registro para aplicaciones no .NET). Si estos ensamblados se van a usar en .NET solo hay que añadirlos al assembly de windows, esto se hace:

1.- Abrimos una aplicacion consola desde el path de Visual Studio.

2.- Escribimos en la linea de comandos: gacutil -I RUTAENSAMBLADO (Ej. gacutil -I c:\midll.dll)

Si necesitamos interoperabilidad con COM hay que registrar el ensamblado en windows. Se hace: regasm /tlb /codebase RUTAENSAMBLADO (Ej. regasm /tlb /codebase c:\rutadll.dll)

Esto debe mostrarte un mensaje de finalización en ingles como que se ha procedido al registro correctamente, en el caso que hubiera alguna incompatibilidad (como hemos comentado antes) de tipos de datos no compatibles con COM, se verá como en este paso la aplicación regasm lo mostrará.

Bueno, después de escribir este tocho “como mi primr HOLA MUNDO” del blog. Espero que lo veáis util y hagamos de esto un blog con bastantes post para ayudar…. un saludo!!