Ya está el blog vivito y coleando, eso sí, tengo que ir post por post corrigiendo tags html puesto que el exportador / importador de wordpress es un poco basurita.

Si a partir del Lunes (dadme unos días para ir corrigiendo ) seguís viendo fallos, dejad un comentario en este post y los corregiré.

Ahora estoy en Arvixe y la verdad, mucho más rápido, muchas más features y mucho más todo

Un saludín.

Voy a hacer un cambio de hosting a uno en mejores condiciones para mi blog y mis pruebas alternativas.

En un principio la URL no va a cambiar en absoluto, simplemente estará una tarde o así sin funcionar, así que si veis porno o algo raro mientras está de mantenimiento, no es culpa mia.

Antes de explicar en qué consiste dicho patrón y de meternos en faena voy a explicar el por qué es útil.

Todos sabemos que nuestra aplicación ideal es aquella donde cada parte de la misma está bien separada de las otras, donde la mantenibilidad sea máxima, donde podamos ampliar por donde queramos sin bloquearnos en partes donde la arquitectura no puede crecer más, aquella que nos permita cambiar una parte de la aplicacion sin efectos secundarios…

Un mundo color de rosa, ¿Verdad? Sin duda.

¿Cuál es el problema? Pues que no podemos hacer algo en plan:

application.AplicacionIdealMode();

Necesitamos cuidar trozo de código que escribamos, debemos organizar bien las clases, desacoplarlas lo máximo posible… Se que es mucho, pero granito a granito hacemos la playa, quiero decir, la aplicación ideal.

Hoy vengo a contaros uno de esos granitos.

Como sabéis, algo que ayuda mucho es dividir la aplicación en capas, por ejemplo en una aplicación WPF pues lo ideal es la vista, el viewmodel, el modelo y… la lógica del negocio.

Lo mismo para una aplicación web, vista, controlador, modelo y la lógica del negocio.

Para este artículo en cuestión lo que nos interesa es la lógica del negocio.

Imaginad que tenéis 15 clases que contienen información que será almacenada en “lo que sea”, una base de datos, a un servidor mail, a un fichero de texto plano… Si hoy decides que todo eso va a texto plano y cada clase se encarga de guardar su información en un .txt, pues será una real gracia cuando mañana tu aplicación crezca y necesites una base de datos para que esto siga avanzando. ¿Qué harás? ¿Cambiar media aplicación para que deje de usar un .txt y ahora use una base de datos? ¿Qué pasa si pasado ya no quieres bases de datos? ¿Y si X clase necesita además enviar datos por email? Suena a mucho lio que te hará perder mucho tiempo.

¿Qué hacemos en este caso? Pues colocar todo lo que sea el acceso a datos, o sea, la persistencia en otro sitio y así desacoplar la aplicación lo máximo posible.

¿Empezamos?

Creamos una nueva solución vacía en Visual Studio (solución en blanco)

Le ponemos de nombre pues: TutoRepositorios

Ahi creamos una nueva libreria de clases llamada: TutoRepositorios.Dominio

Borramos el fichero Class1.cs y creamos un directorio llamado Entidades, dentro de dicho directorio creamos una clase llamada Libro, el código de dicha clase será:

namespace TutoRepositorios.Dominio.Entidades
{
    public class Libro
    {
        public int Id { get; set; }
        public string Nombre { get; set; }
        public string Autor { get; set; }
    }

	public override string ToString()
	{
		return string.Format("Nombre: {0}\nAutor: {1}", Nombre, Autor);
	}
}

Algo sencillito para nuestro ejemplo .

Vamos a crear una aplicación que muestre un listado de libros, para ello vamos a crear crear un repositorio para los libros.

Pero… ¿Qué es un repositorio? Un repositorio es una clase que servirá como intermediario entre nuestra aplicación y nuestros datos, dicho con otras palabras, será una clase que nos ofrecerá una interfaz CRUD (Crear, Obtener, Actualizar, Borrar (Create, Retrieve, Update, Delete en inglés)).

Vamos a implementarla para entenderlo mejor.

¿Cómo lo hacemos? ¿Creamos una clase llamada no sé LibroRepositorio y ahi metemos todo el código? Sí y no, si bien es una forma correcta de hacerlo, por muy poco esfuerzo más podemos añadir unos cuantos granos más a nuestra playa, errr aplicación.

Para ello vamos a crear una interfaz para nuestro repositorio, para ello creamos una nueva carpeta en nuestro dominio llamada: Repositorios, dentro creamos una interfaz llamada: ILibrosRepositorio

namespace TutoRepositorios.Dominio.Repositorios
{
    public interface ILibrosRepositorio
    {
        void Insertar(Libro libro);
        void Borrar(Libro libro);
        Libro Obtener(int id);
		IList<Libro> ObtenerTodos();
        void GuardarCambios();
    }
}

Una interfaz muy sencillita.

Ahora bien, ¿No es esto repetir código? Quiero decir, ¿Para qué una interfaz y luego una clase que la implemente? Fácil, si tienes un repositorio que usa un .txt para persistencia y luego quieres uno para guardar en bases de datos, pues ya tienes una interfaz que declara el cómo ha de ser un repositorio de libros, solo tienes que implementar dicha interfaz y ya está.

No solo eso, para hacer pruebas unitarias esto es un requerimiento.

Imagina que la clase que quieres testear usa el repositorio de libros el cual consulta a una base de datos. ¿No sería contraprudecente testear dicha clase y que ésta a la vez tenga que acceder a la base de datos? Imagina que para la prueba de dicha clase has de crear 10 elementos en el repositorio y luego borrar 3, eso se queda guardado en la base de datos… ¿La solución? Crear un repositorio de mentira para las pruebas, así podrás probar la clase sin depender de la base de datos, y no generarás basura en tus pruebas.

Uhm, interesante… Vamos a crear un repositorio de mentira a ver…

Crea una nueva clase llamada: FakeLibrosRepositorio en la carpeta de repositorios:

namespace TutoRepositorios.Dominio.Repositorios
{
    public class FakeLibrosRepositorio : ILibrosRepositorio
    {
        private IList<Libro> _libros = new List<Libro>();

        public void Insertar(Libro libro)
        {
            _libros.Add(libro);
        }

        public void Borrar(Libro libro)
        {
            _libros.Remove(libro);
        }

        public Libro Obtener(int id)
        {
            return _libros.SingleOrDefault(l => l.Id == id);
        }

        public IList<Libro> ObtenerTodos()
        {
            return _libros.ToList();
        }

        public void GuardarCambios()
        {
            // No necesitamos guardar nada en este repo fake.
        }
    }
}

Como veis, un repositorio muy básico donde realmente no persiste los datos, solo los almacena en una lista.

¿Lo probamos?

Añadimos un nuevo proyecto a nuestra solución, concretamente una aplicación de consola (Que para el caso nos da igual), vamos a llamarla: TutoRepositorios.Consola

Añadimos una referencia del proyecto TutoRpositorios.Dominio para poder usar nuestro repositorio, añadimos el siguiente código de prueba en la clase program.cs

namespace TutoRepositorios.Consola
{
    class Program
    {
        static void Main(string[] args)
        {
            // Creamos un repositorio fake
            ILibrosRepositorio repo = new FakeLibrosRepositorio();

            // Insertamos 3 libros
            repo.Insertar(new Libro {Id = 1, Autor = "Jesus", Nombre = "Operadores de Linq"});
            repo.Insertar(new Libro {Id = 2, Autor = "Alvaro", Nombre = "Php para todos"});
            repo.Insertar(new Libro {Id = 3, Autor = "Manolo", Nombre = "Java Avanzado"});

            // Vamos a impromir el libro con el Id == 1
            Console.WriteLine("Libro Id == 1");
            Console.WriteLine(repo.Obtener(1).ToString() + "\n");

            // Ya no queremos el libro primero, vamos a borrarlo
            var libro = repo.Obtener(1);

            if (libro != null)
                repo.Borrar(libro);

            // Vamos a crear una lista con los libros de nuestro repo
            var libros = repo.ObtenerTodos();

            // Vamos a imprimirlos
            Console.WriteLine("Todos los libros:");
            foreach (var lib in libros)
                Console.WriteLine(lib.ToString() + "\n");
        }
    }
}

Sencillo de usar nuestro repositorio, ¿No? Hemos añadido 3 libros, hemos imprimido uno, borrado otro… La interfaz de nuestro repositorio es muy muy clarita y eso nos facilita el trabajo.

He aquí el patrón repositorio, nada más.

Bueeno, os contaré más, y así verle más la gracia a esto de los repositorios.

Nuestro FakeLibrosRepositorio es un poco basura, ¿Verdad? Si bien funciona, no hay persistencia…

Vaaale vaaale, vamos a persistir los datos en un SQL Server. Para ello nos vamos al explorador de servidores -> Nueva conexión, seeleccinamos SQL Server, colocamos el nombre de nuestro servidor, en mi caso: .\SQLEXPRESS le damos un nombre, por ejemplo: TutoRepositorio.

Ahora creamos una tabla de la siguiente manera:

Acordaros de añadir en la columna “Id” que sea identity, para ello os vais a las propiedades de la columna, buscáis la parte de la especificación de identidad, lo expandís y le dais a que sí en lo de si es identidad (no sé muy bien como estará en castellano).

Vamos a añadir algunos datos de prueba:

Recordad que el Id se pone solo

Vale, ya tenemos la base de datos y algunos datos…

Como esto es un ejemplo, vamos por lo fácil, vamos a tirar de Linq To Sql y vamos a mapear manualmente nuestra clase Libro para que corresponda con la tabla de la base de datos. (En un futuro quiero enseñar como usar la técnica code-first para hacer esto más bonito)

La clase Libro quedaría así:

namespace TutoRepositorios.Dominio.Entidades
{
    [Table(Name = "Libros")]
    public class Libro
    {
        [Column(IsPrimaryKey = true, IsDbGenerated = true, AutoSync=AutoSync.OnInsert)]
        public int Id { get; set; }

        [Column] public string Nombre { get; set; }
        [Column] public string Autor { get; set; }

        public override string ToString()
        {
            return string.Format("Nombre: {0}\nAutor: {1}", Nombre, Autor);
        }
    }
}

[blockquote]
NOTA: Necesitais agregar una referencia de System.Data.Linq al proyecto para poder usar dichos atributos
[/blockquote]

Hecho, ya está eso listo.

Ahora nos toca el repositorio para esto. Como habéis deducido es tan sencillo como crear una clase que implemente nuestra interfaz y ya está. Creamos SqlLibrosRepositorio en la carpeta de repositorios:

namespace TutoRepositorios.Dominio.Repositorios
{
    public class SqlLibrosRepositorio : ILibrosRepositorio
    {
        private DataContext _db;
        private Table<Libro> _libros;

        public SqlLibrosRepositorio(string cadenaConexion)
        {
            _db = new DataContext(cadenaConexion);
            _libros = _db.GetTable<Libro>();
        }

        public void Insertar(Libro libro)
        {
            _libros.InsertOnSubmit(libro);
        }

        public void Borrar(Libro libro)
        {
            _libros.DeleteOnSubmit(libro);
        }

        public Libro Obtener(int id)
        {
            return _libros.SingleOrDefault(l => l.Id == id);
        }

        public IList<Libro> ObtenerTodos()
        {
            return _libros.ToList();
        }

        public void GuardarCambios()
        {
            _db.SubmitChanges();
        }
    }
}

¿Queda muy claro verdad? Te preguntarás el por qué el constructor del repositorio recibe la cadena de conexión en vez de asignarsela directamente dentro del repositorio. Es otro granito de arena más, si injectamos la cadena de conexión en el constructor, podremos reusar este repositorio con cualquier base de datos que queramos

Vale, vamos ahora a usar este repo en nuestra aplicación de consola:

namespace TutoRepositorios.Consola
{
    class Program
    {
        static void Main(string[] args)
        {
            // Creamos un repositorio
            ILibrosRepositorio repo = new SqlLibrosRepositorio(@"Data Source=.\SQLEXPRESS;Initial Catalog=TutoRepositorio;Integrated Security=True");

            // Vamos a impromir el libro con el Id == 1
            Console.WriteLine("Libro Id == 1");
            Console.WriteLine(repo.Obtener(1).ToString() + "\n");

            // Ya no queremos el libro primero, vamos a borrarlo
            var libro = repo.Obtener(1);

            if (libro != null)
                repo.Borrar(libro);

            // Vamos a crear un nuevo libro
            libro = new Libro {Autor = "Pco", Nombre = "Patrones de diseño"};
            repo.Insertar(libro);

            // Ouch, puse Pco en vez de Paco, vamos a actualizarlo
            libro.Autor = "Paco";

            repo.GuardarCambios();

            // Vamos a crear una lista con los libros de nuestro repo
            var libros = repo.ObtenerTodos();

            // Vamos a imprimirlos
            Console.WriteLine("Todos los libros:");
            foreach (var lib in libros)
                Console.WriteLine(lib.ToString() + "\n");
        }
    }
}

Como veis, la forma de usar el repositorio no ha cambiado en absoluto, insertamos y obtenemos libros de la misma forma, usando la misma interfaz. La unica diferencia es que ahora tenemos la posibilidad de persistir nuestros datos

Otra ventaja de esto es que si ahora queremos usar este dominio en no sé, una aplicación ASP.NET MVC pues no tendríamos que cambiar nada, solo usar el repositorio como hemos hecho aquí.

No voy a detallar los pasos, mostraré lo relevante y el resultado:

El controlador que con la acción de mostrar los datos:

namespace TutoRepositorios.WebUi.Controllers
{
    public class HomeController : Controller
    {
        //
        // GET: /Home/

        private ILibrosRepositorio _repo =
            new SqlLibrosRepositorio(
                @"Data Source=.\SQLEXPRESS;Initial Catalog=TutoRepositorio;Integrated Security=True");

        public ActionResult Index()
        {
            var libros = _repo.ObtenerTodos();
            return View(libros);
        }

    }
}

Simplemente creamos el repo, creamos una lista de libros y la enviamos a la vista que la imprime:

¿Habeis visto? ¡Hemos creado una capa de acceso a datos independiente del resto, la hemos usado en una aplicación de consola, en una web y no hay que cambiarla!

Consideraciones finales

El método de guardar los cambios… Es lógico que tenemos que guardar nuestros datos pero… ¿No es un poco pesado tener que ir llamando al dichoso método cada vez que hagamos cambios?

Tenemos dos opciones y las dos perfectamente válidas:

Crear un método que llamaremos explicitamente cuando lo necesitemos (Como hemos hecho aquí). La ventaja que tiene es que nos permite hacer varios cambios al repositorio sin guardar los cambios, lo que nos da flexibilidad, por contra es eso, tenemos que ir llamandolo muchas veces.

No crearlo, guardar implicitamente los cambios en cada método del repositorio que haga cambios a la base de datos. Esto es útil si realmente necesitamos guardar los cambios cada vez que toquemos algo, así nos ahorramos código

Todavía hay más granitos de arena, pero esos ya se salen fuera de este tutorial.

Por ejemplo, todavía se puede desacoplar lo que hemos visto algo más. Echandole un ojo al controlador de este último ejemplo… Estamos instanciando el repositorio ahi a mano, lo que nos quita flexibilidad…. Si queremos testear dicho controlador, nos vamos a tener que tragar ese repositorio, y si queremos cambiarlo por uno Fake como el que ya tenemos, necesitariamos reasignar el repositorio al Fake y bueno, eso no es flexible para nada…

¿La solución? Injección de dependencias, ¿La explicación? En otro artículo

Ahora sí que está esto terminado.

Os dejo el proyecto aquí (.NET 4)

Hasta otra.

En resumen, volveré a escribir artículos, no 20 al mes, pero intentaré escribir todas las cosas interesantes que vaya aprendiendo

Por otro lado, no sé que pasa que si intentas acceder a mi blog en plan:

http://blog.foxandxss.net

o

http://www.foxandxss.net/blog

Te dice que la página no existe, eso si, si ya pones el index.php ya funciona. No sé por qué pasa, pero pasa

Siento no haber escrito mucho últimamente, ya sabéis, exámenes y bueno, estoy dandole caña a la programación web pero nada lo suficientemente interesante por ahora como para escribir un artículo. Por otro lado, tengo un viaje inminente, así que estaré ausente un poco más.

Bueno, a lo que iba… Este post quizás es algo offtopic para lo que es el blog en sí, pero quizá muchos teneis la idea de publicar vuestro libro / proyecto / tesis / …

En mi dia yo tuve muchas dudas sobre el proceso de pasasr de tener mi .doc listo a tener mi libro publicado, así que este post os diré los pasos a seguir además de daros algún consejo para que no cometáis los mismos errores de novato que yo tuve

Preferiblemente antes de empezar tu obra es elegir el tamaño del papel (para evitar reestructurar luego todo el documento). Para ello os dirigís a la siguiente página:

Formatos de libros

Aquí tenéis los formatos de los libros además de plantillas de Microsoft Word para cada formato.

Por ejemplo el típico libro de informática usa el formato Crown Quarto, así que si queréis usar ese, os bajáis la plantilla y escribís vuestra obra ahí.

Vamos a suponer que habéis completado la obra, habéis creado el índice (recordad que Word lo genera automáticamente si queréis).

Importante decir que aunque sea vuestra obra, tenéis que cumplir unos requisitos especificados en ésta página:

Requsitos

A modo de resumen:

• Márgenes correctos (cosa que no os preocupará si usais las plantillas)
• Última página en blanco
• La primera página es la página del título
• La segunda página contendrá el copyright y el ISBN(Lo explico luego)

Vale, ya tenéis el .doc / .docx terminado con los requisitos, la tabla de contenidos y… vuestra obra claro.

NOTA: Tened en cuenta si usais encabezados, que el libro imprimido tendrá la página par a la izquierda y la impar a la derecha, para que luego no os salgan al revés.

NOTA 2: Recordad que tal como lo véis en vuestro documento, será igual en el libro, así que cuidad los margenes, sangrados, etc.

Lulu acepta tanto el .doc / .docx como un .pdf. Eso sí, el .pdf lo tenéis que crear usando Adobe Acrobat puesto que no acepta otra cosa.

Si decidís tirar por el .doc / .docx pues os generará automáticamente el .pdf y además os dejará bajarlo luego para revisar que todo sigue en su sitio.
Si por otro lado decidís crear vosotros el .pdf, tenéis que incrustrar todas las fuentes en el documento, ¿Cómo? Así:

Tutorial para embeber fuentes (En inglés, pero es 90% imágenes )

Vale, ya tenéis vuestra obra lista en cualquiera de los dos formatos.

Ahora toca ir a la página de Lulu, registraros y en vuestro perfil, le dais a nuevo proyecto. Ahora seleccionais el tipo de proyecto a crear, por ejemplo Libro de tapa blanda.

Os pedirá el nombre de la obra y vuestro nombre. Además os dá 3 opciones:

• Mantenerlo privado
• Hacerlo público
• Hacerlo público además de asignarnos un ISBN de forma gratuita.

La opción interesante es la tercera.

En el siguiente paso tenéis que elegir el tipo de papel a usar, el tipo de portada, tamaño de la obra, blanco y negro, color… (Todo esto a vuestra elección).

Luego nos generará un ISBN además de un código de barras. El ISBN como bien dicen los requisitos, ha de aparecer en la segunda página de la obra (Yo metí la imagen del código de barras que ya trae el ISBN colocado).

Una vez llegamos a este paso, es hora de completar nuestra obra. Vamos a la segunda página y colocamos el ISBN y como Copyright, pues también a vuestro gusto, yo personalmente registré mi obra en:

Safe Creative

Así que coloqué tambien el sello que me dan los de Safe Creative junto al ISBN que me dió Lulu.

NOTA: La obra si vais a registrarla, hacedla cuando no le vayáis a meter más cambios, o sea, con el ISBN introducido y tal.

Vale, ya tenemos nuestro ultimismo fichero con el Copyright y el ISBN.

Lulu nos pide ahora que subamos nuestro fichero, aquí comprobará que las fuentes están incrustadas (en el caso de los .pdf) y que no hay nada extraño en el documento.

Toca la portada. Lulu tiene un hermoso editor de portadas que no está nada nada mal, os permitirá elegir entre varios diseños de portada y personalizarlos un poco. Además podéis retocar el lomo a vuestro gusto.

¿Que no os gusta ninguna de las portadas que os ofrece Lulu? Pues nada, os creáis vuestra propia portada (en una sola pieza, o sea, portada + lomo + contraportada en un solo documento).

Hay que tener en cuenta que si creáis la portada, ha de aparecer el nombre de la obra + autor en la portada, el código de barra + isbn en la contraportada…

Bueno, portada lista.

Ahora nos toca escribir la descripción de nuestra obra, esto ya depende de vosotros

Precio… La parte más importante…

Lulu trabaja de la siguiente forma:

Te dan el precio de fabricación de la obra, por ejemplo 7 euros. A ese precio ellos le añaden un pequeño plus para tener una mínima ganancia en el caso de que decidas venderlo a precio de costo. Así que finalmente podría ser algo en plan: 7€ fabricación + 2€ ganancia = 9€ es el precio minimo de la obra. A partir de aquí tu ya le pones las ganancias que tu quieras. De dichas ganancias, el 80% va para ti y el 20% va para Lulu.

Si decides poner un precio de 19€ a tu obra, le restamos los 9€ que es el precio minimo, quedarían 10€, de aquí 8€ van para ti y 2€ van para Lulu. Vamos, ganarías 8€ por unidad vendida.

Por último solo nos queda revisar la obra, ver que todo está en orden y finalmente…. ¡Publicarlo!

Ya está, ya está listo, ya tenéis vuestra obra a la venta y con su bonito ISBN.

¿Último paso? Comprar vuestra propia copia (a precio de coste claro).

Luego Lulu se porta y te regala vales de descuento para que terceras personas aprovechen cosas como 15% de descuento o gasto de envío gratis.

Bueno, espero ver vuestras obras en Lulu algún día

Un saludo.

Vamos a imaginar un sencillo método:

void Saludo(string nombre, int edad, string ciudad)
{
    Console.WriteLine("Hola me llamo {0} tengo {1} años y vivo en {2}", nombre, edad, ciudad);
}

¿Cómo se puede usar este método? Es una respuesta obvia ¿Verdad?:

Saludo("Jesus", 24, "Cádiz");

El problema es que quizá no te acuerdes de si primero pedia la edad o la ciudad… Eso si, sabes como se llaman los parámetros, entonces puedes hacer:

Saludo(nombre: "Jesus", edad: 24, ciudad: "Cádiz");

El resultado es sin duda más legible (aunque más redundante), también podemos hacer algo así:

Saludo(ciudad: "Cádiz", edad: 24, nombre: "Jesus");

Hemos variado el orden de los parámetros, pero como le hemos dado un nombre pues no hay problema en ello.

Ahora bien, por otro lado están los parámetros opcionales.

Por ejemplo, tenemos un método para insertar un elemento a una base de datos, por defecto los elementos van a la categoría Sin Categoría a menos que especifiquemos lo contrario:

static void InsertarElemento(string nombre, string categoria = "Sin Categoria", bool debug = false)
{
    if (debug)
        Console.WriteLine("Nombre: {0}\nCategoria: {1}", nombre, categoria);

    // Insertar en base de datos
}

Fijamos en la sintaxis del método, le hemos asignado un valor a un par de parámetros. Con esto queremos decirle que esos parámetros son opcionales, no tenemos por qué darles un valor al llamar al método, y en caso de no hacerlo usará esos valores asignados (el nombre sin embargo si es obligatorio), por ejemplo:

InsertarElemento("Canasta");

Con esto asignamos a la base de datos un elemento con el nombre Canasta y como categoría Sin Categoría.

¿Que queremos darle una categoria nosotros y ademas activar el modo debug?:

InsertarElemento("Canasta", "Mimbre", true);

Hemos asignado un valor nuevo a los dos parámetros opcionales, al estar el modo debug activado, antes de insertar el elemento en la base de datos, lo imprimirá:

Nombre: Canasta
Categoria: Mimbre

Lo bueno de esto es que podemos usar los parámetros opcionales y con nombre a la vez, por ejemplo, ¿Cómo podríamos activar el modo debug sin cambiar la categoría por defecto?

Tenemos que hacer uso de los parámetros con nombre, o sea:

InsertarElemento("Canasta", debug: true);

Nos hemos “saltado” el parámetro de la categoría gracias a los parámetros con nombre.

Esto imprimiría:

Nombre: Canasta
Categoria: Sin Categoria

Los parámetros opcionales y con nombre son muy útiles a la hora de trabajar con COM ya que estos métodos suelen recibir hasta una docena de parámetros opcionales y quizá solo uno importante… Antes teníamos que especificarlos todos, ahora simplemente podemos especificar el importante e ignorar el resto.

Hoy es un dia feliz para mí, despues de muchas horas de trabajo, he conseguido terminar, pasar a limpio, y en fin, crear el libro de los operadores de Linq.

Ya está listro para la compra en Lulu una página que recomiendo a todo el mundo sin duda.

Espero que sea del agrado de todo el mundo y que os sirva de ayuda en vuestros desarrollos.

Sin más, hasta el próximo artículo.

Para eso está “Windows Presentation Foundation Unleashed” de Sams.

Windows Presentation Foundation Unleashed (WPF-U a partir de ahora) ha sido aclamado como el mejor libro de WPF que había en el mercado. Ya han pasado 4 años del lanzamiento (2006) pero sigue siendo igual de util a dia de hoy.

Nada mas abrir el libro, te enamoras de el, pues está a todo color, lleno de imagenes con colores vivos, el código tal y como lo verás en Visual Studio y lleno de recuadros con información. Precioso sin duda.

Ya hablando del libro en si, está muy bien como la gente aclama aunque yo le veo algunos fallitos.

Tiene un comienzo muy muy duro, los 3 primeros temas volverán loco a cualquiera que se quiera meter con WPF, ya que te cuenta TODO lo que ofrece WPF y claro, empiezas a leer sobre Dependency properties, Commands, Routed events, Markup extensions y claro lo más lógico es decir algo en plan: ¿Pero que carajo es todo esto? Si apenas hemos visto 3 líneas de XAML…

La verdad, esta primera parte es un trago complicado, pero ya luego empieza a explicar las cosas paso a paso y empieza lo bueno.

Tiene una buena parte explicando los controles que WPF nos ofrece, como cambiarles el tamaño, aplicarles transformaciones tales como rotaciones… Sigue explicandos como estructurar una aplicación visualmente usando los Layouts que WPF nos pone a nuestra disposición. Incluso nos dice como hacer ventanas tipo Vista o Win 7, con sus bordes de cristal y tal.

Despues de la introducción a WPF ya se mete a temas más avanzados como los Data Bindings, estilos, temas…

Luego continua hablandonos de graficos en 2D y 3D, animaciones, meter audio y video en nuestras aplicaciones…

Termina hablandonos un poco de como funciona la interoperabilidad con Win32, Windows Forms y ActiveX además de darnos una pequeña explicación de qué es un control de usuario y como crear controles personalizados (de una forma muy muy básica).

En resumen, es un libro bueno, toca casi todo lo que WPF ofrece, aunque algunos temas pecan de ser simplones y otros quizás menos interesantes los explica a fondo…

El problema que yo le veo al libro, es que se escribió cuando WPF era bastante nuevo, y a dia de hoy algunas de las cosas que el libro explica pues ya no se hacen de esa forma o incluso he visto un par de cosas que ya no eran ni válidas.

Aún así sigue siendo una de las mejores opciones para aprender WPF, hay alternativas, pero dan sueño.

Cosas positivas:

• Buenísisisima presentación
• Te muestra casi todo lo que WPF ofrece
• Muchos de los temas están muy bien explicados
• La parte de interoperabilidad está bastante bien

Cosas negativas:

• Algunas cosas que explica ya no son validas
• Tiene algún fallito que otro
• La introducción da miedo de verdad
• Algun tema es bastante simplón y hasta sobraría

Yo le doy un 8 a este libro.

Como nota final, yo para los que se quieren iniciar en WPF, aparte de leer mi blog a diario, les recomiendo primero leer el libro WPF in 24 Hours y luego leer WPF-U.

Una pena que ambos estén solo en inglés, pero es lo que tiene la informática y concretamente WPF que no tiene tanto impacto (por ahora) en el mundo hispano.

Hasta otra.

Hace tiempo que tenia ganas de cambiar el diseño del blog, no sé, estaba harto del azul que tenía (que no era feo, cuidado).

Quería uno fluid porque la verdad, el código a veces quedaba muy apretado y no era cómodo de ver.

Me puse en busca y captura de un tema fluid que me gustara pero no veía ninguno así molón. Así que intenté convertir el mio en fluid (no tuve cojones jeje).

Así que bueno, me he creado mi propio tema desde 0.

Si encontrais fallos no me peguéis, es la primera vez que toco css y puede o bien tener redundancia en el css o petar haciendo algo raro jeje.

Si encontráis fallos ponedme un comentario aquí e iré arreglando los que vayan saliendo.

Por otro lado a ver si termino el pdf del libro de linq para que le echéis un ojo y estos días escribiré una reseña de un libro de WPF para no dejaros aquí solitos

El día que le dije a mi amigo Ilgrim, oye, me voy a currar una referencia de los operadores de LINQ, no pensaba en su día que me iba a llevar tantísimas horas, cada post tiene sus 2-3-4 horas de trabajo, y son 14 familias…

Bueno, ya está terminada, ahi tenéis todos los operadores con todas sus sobrecargas.

Ahora lo pasaré a pdf y lo mandaré a imprimir para los que queráis tener una copia impresa.

El pdf lo publicaré bajo licencia CC y me gustaría que todos le echarais un vistazo para comentar que cosas podría mejorar o cambiar de cara a enviarlo a imprimir. Aunque esto ya podéis hacerlo dejando un comentario en los posts de cada familia de opreadores.

Y bueno, estaré unos días sin escribir nada en el blog, voy a descansar un poco, dedicarme a otras tareas atrasadas y a buscar nuevas ideas para el blog, ya que realmente no sé de que escribir ahora, tanto LINQ tanto LINQ que ya ni me acuerdo de que era WPF

Bueno, pues hasta el siguiente post

Ah, y gracias por leerme aunque luego os cueste dejar comentarios y feedback