Para evitar problemas de seguridad en ADO.NET 2.0 es recomendable componer las sentencias SQL a base de parámetros en lugar de construir las cadenas manualmente en base a las propiedades .Text de los controles u otros orígenes. De esta forma evitamos fallos de seguridad potenciales (ie: SQL Injection) y otros problemas menores. Siguiendo con nuestra DB Factory donde mostré como utilizar la Fábrica de objetos de ADO.NET 2.0 para construir objetos que pueden manejar cualquier base de datos, ahora le toca el turno a la clase DbParameter para añadir parámetros a las sentencias SQL de nuestra DB Factory.

Mas...

Esto lo ví una vez y a raiz de una pregunta en el foro lo busqué de nuevo. Se trata de como localizar las rutas a las carpetas especiales de Windows desde .NET, aunque existe una variable de entorno %homepath% apuntando a nuestra carpeta personal en el sistema, no hay ninguna para llegar a carpetas como 'Escritorio', 'Mis Imágenes', 'Mi Música', ... etc ... y dependiendo del idioma en el que este el sistema operativo, pueden llamarse 'Desktop', 'My Pictures', 'My Music', ...etc...

Mas...

Me gusta todo lo relacionado con IT, puedo construir lo que que quiera, mi herramienta es un ordenador y mis materias primas la imaginación y el conocimiento, el límite esta en cuanto puedo aprender, eso me hace sentirme... bien. Empece en telecomunicaciones, pasé a sistemas y fortuitamente empecé a programar con VB6 y después con Delphi, cuando descubrí C# y .NET decidí dedicarme únicamente a ello pues me encantaba, me resultaba creativo y divertido. Llevo escasos dos años en el mundo del desarrollo en continuo avance para mejorar, pero últimamente estoy algo desmoralizado pues después de haber estado este tiempo desarrollando en plan "ágil", ahora he chocado frontalmente con los conceptos de software factory y pool de programadores, formas de convertir el desarrollo en una cadena de montaje sin sentido supuestamente en pos de la máxima productividad y a mi parecer en decrimento de la calidad, la innovación y la creatividad, formas que ya no me parecen divertidas ni motivadoras.

Mas...

El modelado en capas de un sistema representa como se planea dividir el código en partes lógicas ó grupos. La abstracción del código en capas permite mejorar, reparar y reemplazar partes de la aplicación de forma sencilla y sin que afecte a las demás. Además provee una representación lógica y clara de la aplicación.

El modelo en capas más comun es el de tres capas, presentación, lógica de negocio y base de datos. El model n-capas extiende este modelo de forma que cualquier capa puede dividirse en subcapas, aportando así mayor claridad.

La capa más alta es en la que se interactua con el usuario, la capa más baja donde los datos son almacenados/recuperados y las capas intermedias son las encargadas de realizar el procesado de datos, el movimiento de estos de la base de datos al usuario y el control del estado de la aplicación.

Mas...

Consejos y trucos para el rendimiento de la biblioteca de clases base,  así se titula un articulo de CLR Inside Out (en castellano) que explica buenas prácticas y trucos para mejorar el rendimiento que creo que merece la pena leer.

Aviso, no contiene conjuros ni hechizos que hagan que una aplicación chatarra mágicamente vuele y mejore su consumo de RAM.

La mejora del rendimiento en la mayoria de los casos es una cuestión de diseño y de la suma de infinidad de pequeñas cosas como las que se comenta en este artículo. Utilizar una instrucción más optima que otra no nos hace ganar segundos, ni milisegundos, ganamos ciclos de CPU; es la suma de elecciones correctas durante el desarrollo y el correcto uso del framework lo que nos da la mejora tangible de rendimiento deseada. Pero no hay que olvidar la importancia de un buen diseño, por ejemplo si yo quisiese crear una bicicleta de carreras para correr el "Tour" y hago un triciclo de niños, por muy aerodinámico que sea, cuadro de fibra de carbono y ruedas Michelin .... sigue siendo un triciclo.

Un modelo lógico representa los conceptos reales que ha de cubrir la aplicación y permite asegurar que el software cubrirá dichos conceptos.

El modelado de funciones de objetos (Object Role Modeling - ORM) es el proceso de representar conceptos del mundo real que definen ó influyen en el software. Los diagramas ORM incluyen unos objetos primarios llamados entidades, las relaciones entre esas entidades y los atributos que definen esos objetos. Estos diagramas se crean descomponiendo los requerimientos de usuario y los casos de uso en entidades, relaciones y atributos.

Mas...

Ya había comentado en alguna ocasión que una de las personas que admiro por su dedicación y sobre todo por su objetividad y temple es Miguel de Icaza, asalariado de Novell y lider de los proyectos de software libre Gnome y Mono. Miguel es uno de los desarolladores del mundo open-source que más estrechamente trabaja con Microsoft con el proyecto Mono (implementación libre de .NET) y Moonlight (implementación libre de Silverlight). Los más radicales y descerebrados del mundillo del software libre lo critican a él por esta proximidad a Microsoft y a su trabajo por, según ellos, "traer Microsoft a Linux" (juicios, patentes, copyright, ...etc..).

Mas...

Después de evaluar los requerimientos y el diseño previo de una aplicación, el siguiente paso es realizar un prototipo.

Un prototipo tiene el propósito de cubrir los huecos  que quedan entre la teoría y la práctica, es decir, entre los requerimientos junto el diseño y la implementación real.

Las maquetas se usan para proponer y validar interfaces de usuario y la navegación por el sistema. Se pueden crear desde con papel y lapiz a herramientas como Microsoft Visio. También se conocen como prototipos horizontales y verifican el cumplimiento de los requerimientos y casos de uso a través de una serie de formularios clave.

Los prototipos de prueba de concepto prueban la arquitectura propuesta con todas sus capas, se conoce también como arquitectura de referencia. Se deben crear con las tecnologías propuestas ó aproximadas. También se conocen como prototipos verticales (por lo de que influyen todas las capas).

Mas...

Los requerimientos de un proyecto deberían ser definidos desde múltiples perspectivas:  

• Requerimientos del negocio: Definidos por los gerentes y comerciales. Exponen que puntos se consideran importantes para el éxito del proyecto.
• Requerimientos de usuario: Definidos por los futuros usuarios. Exponen que tareas deben ser capaces de realizar con la aplicación para cumplir los objetivos de su trabajo.
• Requerimientos funcionales ó especificaciones funcionales: Definidos por el lider técnico ó el arquitecto. Definen las caracteristicas que se deben desarrollar para cumplir los requerimientos anteriores. Son definidos mejor a través de herramientas de modelado, sin tener que hacer por un lado un documento de requerimientos y por otro el modelado de dichos requerimientos.
• Requerimientos de calidad de servicio: Definen requerimientos sobre el rendimiento, escalabilidad y estandares a cumplir, no sobre aspectos funcionales ó problemas específicos.

Unos requerimientos bien expuestos no deberian presentar ambiguedad. No deben exponer metas a conseguir, si no cosas que se pueden hacer y estimar. No deben dar lugar a malas interpretaciones.

Mas...

Siguiendo con lo de enviar un archivo por eMail, puede ser que lo que queramos enviar no este en el sistema de archivos, si no que este en la memoria de nuestro programa. Un ejemplo de esto es que exportemos el contenido de un DataGridView a formato Excel ó hayamos dibujado un gráfico con GDI+ ... ó cualquier cosa que se os ocurra ... y lo queramos enviar por eMail como archivo adjunto, al igual que enviar un Stream por FTP, enviar un Stream como archivo adjunto también pude ser muy útil.

Ahí va un sencillo ejemplo:

Mas...