Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.

Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

UML se utiliza en algunas herramientas que generan código a partir de un diagrama de clases por ejemplo. De manera más general el Object managment Group (OMG) ha desarrollado el concepto de arquitectura dirigida por modelos (model-driven architecture, MDA). Este enfoque pudiera ser a un nivel de abstracción y generalización demasiado alto para ser de uso practico.

MDA enfatiza independencia de plataforma. En la práctica, esto no puede ser un absoluto. Las caracterí­sticas de una tecnología o implementación son restricciones en el modelo.

MDA asume que están disponibles modelos para cualquier artefacto.

MDA utiliza UML como lenguaje de uso general. Algunas tecnologías y aplicaciones no se prestan para ser representados en UML y se pueden describir mejor con herramientas especí­ficas que permitan una mayor fidelidad al pasar de concepto a implementación.

MDA asume que 3 tipos de modelo son suficientes:

computation-independent model,

platform-independent model,

platform-specific model.

MDA se enfoca en transformaciones. Es difí­cil lograr un proceso completamente automático que vaya de concepto a implementación. La metodología debe incluir el manejo de la parte variable que no se puede automatizar y los cambos que se requieran durante el mantenimiento de una aplicación

Un lenguaje de modelación de uso general como UML esta diseñado para soportar el desarrollo de modelos que sirvan principalmente como documentación. Estos lenguajes pueden describir cualquier dominio, pero necesariamente de manera imprecisa por el alto nivel de abstracción que utilizan. En el caso de UML, las abstracciones genéricas se definen utilizando lenguaje natural informal.

Un lenguaje de domino especifico (DSL), esta diseñado para describir con precisión una tarea especifica. En vez de abstracciones genéricas utiliza conceptos tomados directamente de la tarea a modelar.

El concepto de fabricas de software de Microsoft utiliza como componente básicos leguajes de alta fidelidad como XML, C# y SQL, lenguajes de domino especifico (Domain Specific Language, DSL), scripts de flujos de trabajo (workflow), archivos WSDL, archivos DDL, SQL.

Las fábricas de software son especí­ficas a subsistemas como administración de clientes, administración de catálogos, cumplimiento de órdenes.

El machote (template) de una fábrica de software incluye código y metadata que se pueden cargar en un IDE o en una herramienta de desarrollo de aplicaciones empresariales. El concepto de machote es similar al de un machote de un documento de Word o Excel.

El uso de una fábrica de software incluye los siguientes pasos:

  • Análisis de problema. Primero determinar si el producto cae dentro del alcance de la fábrica de software.
  • Especificación del producto. Definir los requerimientos del producto en términos de sus diferencias con los requerimientos de los componentes de la fábrica de software.
  • Arquitecta del producto. Ajustar la fabrica de software a las características particulares del producto.
  • Implementación. Las actividades usuales de pruebas unitarias, pruebas de ejecución, ensamblaje de componentes, desarrollo de componentes
  • Instalación. Crear o re usar restricciones, configuración de infraestructura, validaciones, instalación de requerimientos y ejecutalbes.
  • Pruebas. Crear o re usar recursos de pruebas, datos de prueba, scripts de prueba, uso de herramientas de medición.

Las fábricas de software proporcionan un enfoque robusto a la creación de software usando un paradigma de modelación visual, pero va más allá del uso de modelos como documentación. Usando DSL y XML permiten usar metadata para automatizar la generación de código. Los cuatro pilares de las fábricas de software son: Líneas de software, marcos arquitectónicos (architecture frameworks), desarrollo dirigido por modelos, y guías contextuales

El esquema de fábrica de software es un modelo diseñado para soportar cómputo. El esquema de una fábrica es un árbol. Cada nodo en el árbol se conoce como una perspectiva (viewpoint). La perspectiva raíz corresponde a construir todo el entregable. Las perspectivas subyacentes se derivan por descomposición. Cada perspectiva describe la solución en términos de actividades a realizar y una explicación como realizar cada actividad. Las actividades se describen en términos de los productos que generan. Esto productos son los componentes que se utilizan para construir el entregable. Además cada perspectiva incluye recursos suministrados por la fábrica para resolver los problemas del dominio, generalmente automatizando total o parcialmente la tarea.

Par construir una fabrica se empieza sencillo con recursos simples y se va invirtiendo tiempo en desarrollar recursos más sofisticados conforme se va ganando experiencia en el dominio.

Referencias:

Bare-Naked Languages or What Not to Model

CodeGen’ing a Data Access Layer with CodeSmith

LLBLGen

Microsoft DSL

CodeSmith Community: .netTiers

Sean Mccormack’s Codus

Software Factories

Wilson OR Mapper templates for CodeSmith

Codegeneration.net

Can you code gen everything?

CodeSmith Community: Rocky CSLA Templates

Deklarit Kathleen Dollard

CodeSmith Community: Files

Andres Aguiar’s Blog

Eric Smith’s Blog

.nettiers demo/tutorial DAL in 15 mins

Global Bank Scenario

Visual Studio 2005 SDK Version 4.0

http://blogs.msdn.com/jackgr/

Jack Greenfield’s Blog

Code Generation Network

TypeBuilderLib, a Library to Build Dynamic Types Easily

.NET Compact Framework 2.0

OpenNETCF.org es un repositorio de información y código fuente sobre Microsoft .NET Compact Framework. OpenNETCF.org empezó como un proyecto de código abierto para extender la funcionalidad de .Net 1.x. A partir del Smart Device Framework 2.0 el código fuente dejo de ser libre.

En el mismo sito de Microsoft hay referencias a ejemplos de aplicaciones móviles que usan las extensiones de OpenNETCF.

El articulo Building a Wi-Fi Discovery Application with the .NET Compact Framework 2.0 explica a detalle una aplicación que usa estas librerías e incluye código fuente. Es un buen ejemplo para empezar a ver el ciclo complete de una aplicación móvil no trivial.

La solución de muestra incluye dos proyectos. La aplicación en si, y el código fuente OpenNETCF referenciado en la misma. Al construir la solución en Visual Studio 2005 se marcan warnings pero los proyectos se construyen con éxito. Se puede probar la aplicación en una Pocket PC 2003. Si la tarjetea de WiFi esta desactivada la aplicación genera una excepción. No es una aplicación de grado comercial pero es una buena referencia de lo que se puede hacer.

El articulo Deploying .NET Compact Framework 2.0 Applications with .cab and .msi Files continua con este ejemplo y explica como hacer un proyecto de instalación.

En un proyecto para aplicaciones inteligentes, cada archivo se marca con una acción de generación que se define en la ventana Propiedades del modo siguiente:

  • Un archivo marcado como Compile, valor predeterminado para todos los archivos y formularios de código, compilará los archivos en el ensamblado resultante.
  • Un archivo marcado como Content permite el empaquetado del archivo en el archivo .cab y su implementación en el proyecto. Asimismo, resulta útil para la implementación de archivos de configuración XML y bases de datos SQL Server CE.
  • Un archivo marcado como None simplemente se ignora. Esta acción resulta útil para incluir documentación en el proyecto, como diagramas de Visio que no se deben implementar.
  • Un archivo marcado como Embedded Resource se incluye en el ensamblado ejecutable como un recurso. Esta acción permite que el código escrito extraiga el recurso mediante programación. Asimismo, resulta eficaz para empaquetar imágenes y archivos de secuencias de comandos que se pueden utilizar posteriormente en la aplicación.


Antes de pasar a construir la aplicación para dispositivos inteligentes y crear los archivos .cab para la implementación, no se debe olvidar cambiar el modo de generación del proyecto de depuración a liberación. Esto reducirá el tamaño del ejecutable en el dispositivo (hecho importante en el caso de los dispositivos inteligentes de almacenamiento restringido) y aumentará la velocidad de ejecución.

Para hacer un proyecto de instalación automatica es necesario efectuar los siguientes pasos:

1. Crear archivos .cab para cada dispositivo donde va a correr la aplicación. Un .cab de instalación puede contener un archivo setup.dll con código no administrado, y por eso se requiere un .cab diferente para cada familia de procesadores. Si la aplicación no requiere de este archivo, entonces un solo .cab es suficiente.

2. Agregar los archivos y entradas de registro de la aplicación a los .cab

3. Proveer el código de acciones especiales a ejecutar durante la instalación y desinstalación de la aplicación.

4. Registrar la aplicación con ActiveSync para que se pueda instalar de la PC de escritorio a la Pocket PC.

5. Empacar todo en un archivo .msi

El primer paso es agregar un proyecto
Other Project types->Setup and deployment->Smart Device Cab Project
a la solución.

Al construir el proyecto se generan 3 archivos un .cab, un .log, y un .inf. El archivo .inf tiene parámetros de instalación que serán usados por ActiveSync.

El .cab es suficiente para instalar una aplicación en la Pocket PC pero es posible agregar un proyecto de instalación de escritorio para simplificar el proceso para el usuario.

Para aplicaciones móviles, hay dos cosas que el instalador debe hacer. Debe presentarle al usuario las pantallas del asistente de instalación en la PC de escritorio y debe instalar la aplicación en la Pocket PC.

La instalación en el Pocket PC se hace a través una aplicación llamada CeAppMgr.exe que es parte de ActiveSync. CeAppMgr.exe requires un archivo .ini que se debe agregar manualmente. En nuestro caso el .ini contiene lo siguiente:

[CEAppManager]
Version = 1.0
Component = OpenNETCF WiFiDiscovery

[OpenNETCF WiFiDiscovery]
Description = Sample WiFi Network Discovery Application using the SDF
CabFiles = WiFiDiscovery.cab

Para activar el modo de depuración de CeAppMgr.exe es necesario meterle mano al Registry. Para los valientes

[HKLMSoftwareMicrosoftWindows CE ServicesAppMgr]
“ReportErrors”=dword:1

Existen algunos requerimientos que, aunque no son estrictamente necesarios técnicamente, son prácticas establecidas y necesarias para certificación.

Aplicaciones registradas con CeAppMgr deben estar en un subfolder de ActiveSync por ejemplo. Estos requerimientos los maneja el instalador utilizando variables predefinidas de Windows para mayor flexibilidad y para facilitar localización del software en varios idiomas. Para ejecutar estas acciones se agrega una clase de instalación.

Agregamos un proyecto de librerí­a de Windows a la solución de Visual Studio. A este proyecto le agregamos la installer class. Esta clase soporta eventos relacionados con el proceso de instalación y permite definir acciones previas y posteriores al proceso de instalación y al de desinstalación. Por ejemplo,

public CustomInstaller()
{
InitializeComponent();
this.BeforeInstall +=
new InstallEventHandler(CustomInstaller_BeforeInstall);
this.AfterInstall +=
new InstallEventHandler(CustomInstaller_AfterInstall);
this.BeforeUninstall +=
new InstallEventHandler(CustomInstaller_BeforeUninstall);
}

Es necesario definir constantes para usar dentro del código en términos de entradas en el Registry, bajo la llave HKLM.

De esta manera el código sigue siendo valido bajo distintos idiomas y versiones de Windows.

private const string CEAPPMGR_PATH =
@”SOFTWAREMicrosoftWindowsCurrentVersionApp PathsCEAPPMGR.EXE”;
private const string ACTIVESYNC_INSTALL_PATH =
@”SOFTWAREMicrosoftWindows CE Services”;
private const string INSTALLED_DIR = “InstalledDir”;
private const string CEAPPMGR_EXE_FILE = @”CEAPPMGR.EXE”;
private const string CEAPPMGR_INI_FILE = @”WiFiDiscovery.ini”;
private const string APP_SUBDIR = @”OpenNETCF WiFiDiscovery”;
private string TEMP_PATH =
Environment.SystemDirectory + @”TEMPWiFiDiscovery”;

El ultimo paso es crear el proyecto de instalación.

Other project types ->Setup and deployment->Setup project

Despues de crear el proyecto, realizamos las siguientes acciones:

1. Cambiar el nombre del archivo de salida.

2. Indicar la ubicación de un directorio para guardar archivos temporales. Este direcorio debe estar ubicado de acuerdo a lo que definimos en la clase de instalación.

3. Definir las propiedades del proyecto como compañí­a, nombre de aplicación, etc.

4. Agregar los archivos de salida del proyecto CAB

5. Agregar en la carpeta de aplicación la salida de la clase de instalación

6. Agregar Custom Action usando la clase de instalación

7. Agregar archivo .ini

8. Construir todos los proyectos en la solución

9. Probar el instalador

Para mayor detalle se pueden consultar los articulos originales en el sitio de Microsoft.

El articulo Developing and Deploying Pocket PC Setup Applications aunque obsoleto tiene información complementaria y discute el caso .Net 1.x

Antes de poder ejecutar la aplicación, es preciso instalar .NET Compact Framework en el dispositivo. Si la aplicación requiere SQL Server CE, también será necesario instalar el archivo .cab adecuado. Aunque ambos se instalan automáticamente al implementar la aplicación desde Visual Studio .NET mediante el menú Implementar o al depurar el dispositivo, en producción será necesario emplear un mecanismo diferente.

Como se mencionó anteriormente, los archivos .cab creados para un proyecto no incluyen los archivos .cab correspondientes a .NET Compact Framework o SQL Server CE. Aunque Pocket PC 2003, y dispositivos posteriores, suelen incluir .NET Compact Framework en ROM, será preciso agregar los archivos .cab específicos de la plataforma en cuestión en el caso en que dichos dispositivos no los incluyan. Un modo sencillo de llevar a cabo esta operación para .NET Compact Framework es descargar y ejecutar el redistribuible.

Referencia:

Patrones de implementación para Microsoft .NET Compact Framework

ASP.Net Security

tecnologias ASP.NetMake sure you are very familiar with the following terms:

  • Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers.
  • Authorization. Defining what authenticated clients are allowed to see and do within the application.
  • Secure Communications. Ensuring that messages remain private and unaltered as they cross networks.
  • Impersonation. This is the technique used by a server application to access resources on behalf of a client. The client’s security context is used for access checks performed by the server.
  • Delegation. An extended form of impersonation that allows a server process that is performing work on behalf of a client, to access resources on a remote computer. This capability is natively provided by Kerberos on Microsoft® Windows® 2000 and later operating systems. Conventional impersonation (for example, that provided by NTLM) allows only a single network hop. When NTLM impersonation is used, the one hop is used between the client and server computers, restricting the server to local resource access while impersonating.
  • Security Context. Security context is a generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread. The attributes from a process’ logon session and access token combine to form the security context of the process.
  • Identity. Identity refers to a characteristic of a user or service that can uniquely identify it. For example, this is often a display name, which often takes the form authority/user name.

Principles

There are a number of overarching principles that apply to the guidance. The following summarizes these principles:

  • Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges.
  • Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
  • Don’t trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, cross-site scripting attacks, and buffer overflow.
  • Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.
  • Don’t rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it’s better to use platform features or proven techniques for securing your data.
  • Check at the gate. You don’t always need to flow a user’s security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller’s security context all the way through to your application’s data tier.
  • Assume external systems are insecure. If you don’t own it, don’t assume security is taken care of for you.
  • Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don’t expose any more information than is required when returning an error message to the end user.
  • Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don’t include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
  • Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.
  • If you don’t use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn’t use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

The following steps identify a process that will help you develop an authentication and authorization strategy for your application:

  1. Identify resources
  2. Choose an authorization strategy
  3. Choose the identities used for resource access
  4. Consider identity flow
  5. Choose an authentication approach
  6. Decide how to flow identity

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.

Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

UML se utiliza en algunas herramientas que generan código a partir de un diagrama de clases por ejemplo. De manera más general el Object managment Group (OMG) ha desarrollado el concepto de arquitectura dirigida por modelos (model-driven architecture, MDA). Este enfoque pudiera ser a un nivel de abstracción y generalización demasiado alto para ser de uso practico.

MDA enfatiza independencia de plataforma. En la práctica, esto no puede ser un absoluto. Las caracterí­sticas de una tecnología o implementación son restricciones en el modelo.

MDA asume que están disponibles modelos para cualquier artefacto.

MDA utiliza UML como lenguaje de uso general. Algunas tecnologías y aplicaciones no se prestan para ser representados en UML y se pueden describir mejor con herramientas especí­ficas que permitan una mayor fidelidad al pasar de concepto a implementación.

MDA asume que 3 tipos de modelo son suficientes:

computation-independent model,

platform-independent model,

platform-specific model.

MDA se enfoca en transformaciones. Es difí­cil lograr un proceso completamente automático que vaya de concepto a implementación. La metodología debe incluir el manejo de la parte variable que no se puede automatizar y los cambos que se requieran durante el mantenimiento de una aplicación

Un lenguaje de modelación de uso general como UML esta diseñado para soportar el desarrollo de modelos que sirvan principalmente como documentación. Estos lenguajes pueden describir cualquier dominio, pero necesariamente de manera imprecisa por el alto nivel de abstracción que utilizan. En el caso de UML, las abstracciones genéricas se definen utilizando lenguaje natural informal.

Un lenguaje de domino especifico (DSL), esta diseñado para describir con precisión una tarea especifica. En vez de abstracciones genéricas utiliza conceptos tomados directamente de la tarea a modelar.

El concepto de fabricas de software de Microsoft utiliza como componente básicos leguajes de alta fidelidad como XML, C# y SQL, lenguajes de domino especifico (Domain Specific Language, DSL), scripts de flujos de trabajo (workflow), archivos WSDL, archivos DDL, SQL.

Las fábricas de software son especí­ficas a subsistemas como administración de clientes, administración de catálogos, cumplimiento de órdenes.

El machote (template) de una fábrica de software incluye código y metadata que se pueden cargar en un IDE o en una herramienta de desarrollo de aplicaciones empresariales. El concepto de machote es similar al de un machote de un documento de Word o Excel.

El uso de una fábrica de software incluye los siguientes pasos:

  • Análisis de problema. Primero determinar si el producto cae dentro del alcance de la fábrica de software.
  • Especificación del producto. Definir los requerimientos del producto en términos de sus diferencias con los requerimientos de los componentes de la fábrica de software.
  • Arquitecta del producto. Ajustar la fabrica de software a las características particulares del producto.
  • Implementación. Las actividades usuales de pruebas unitarias, pruebas de ejecución, ensamblaje de componentes, desarrollo de componentes
  • Instalación. Crear o re usar restricciones, configuración de infraestructura, validaciones, instalación de requerimientos y ejecutalbes.
  • Pruebas. Crear o re usar recursos de pruebas, datos de prueba, scripts de prueba, uso de herramientas de medición.

Las fábricas de software proporcionan un enfoque robusto a la creación de software usando un paradigma de modelación visual, pero va más allá del uso de modelos como documentación. Usando DSL y XML permiten usar metadata para automatizar la generación de código. Los cuatro pilares de las fábricas de software son: Líneas de software, marcos arquitectónicos (architecture frameworks), desarrollo dirigido por modelos, y guías contextuales

El esquema de fábrica de software es un modelo diseñado para soportar cómputo. El esquema de una fábrica es un árbol. Cada nodo en el árbol se conoce como una perspectiva (viewpoint). La perspectiva raíz corresponde a construir todo el entregable. Las perspectivas subyacentes se derivan por descomposición. Cada perspectiva describe la solución en términos de actividades a realizar y una explicación como realizar cada actividad. Las actividades se describen en términos de los productos que generan. Esto productos son los componentes que se utilizan para construir el entregable. Además cada perspectiva incluye recursos suministrados por la fábrica para resolver los problemas del dominio, generalmente automatizando total o parcialmente la tarea.

Par construir una fabrica se empieza sencillo con recursos simples y se va invirtiendo tiempo en desarrollar recursos más sofisticados conforme se va ganando experiencia en el dominio.

Referencias:

Bare-Naked Languages or What Not to Model

CodeGen’ing a Data Access Layer with CodeSmith

LLBLGen

Microsoft DSL

CodeSmith Community: .netTiers

Sean Mccormack’s Codus

Software Factories

Wilson OR Mapper templates for CodeSmith

Codegeneration.net

Can you code gen everything?

CodeSmith Community: Rocky CSLA Templates

Deklarit Kathleen Dollard

CodeSmith Community: Files

Andres Aguiar’s Blog

Eric Smith’s Blog

.nettiers demo/tutorial DAL in 15 mins

Global Bank Scenario

Visual Studio 2005 SDK Version 4.0

http://blogs.msdn.com/jackgr/

Jack Greenfield’s Blog

Code Generation Network

TypeBuilderLib, a Library to Build Dynamic Types Easily

Programación orientada a aspectos

Tal vez sea porque estamos a principios de siglo o simplemente un espejismo pero pareciera que estamos en los albores de un cambio paradigmático en el desarrollo de software post orientación a objetos.



Uno de los ideales del desarrollo de software es la capacidad de modificar el funcionamiento de un sistema sin tocar una línea de código. Algunos enfoques en este sentido es inyección de dependencias y programación orientada a aspectos (AOP).

David Hayden en su bitácora presenta un ejemplo, en el contexto de la librería empresarial del grupo de patrones y practicas de Microsoft, del uso del bloque de aplicación de inyección de políticas para guardar registros de llamadas a métodos y se quejaba de que la librería en realidad no soporta el patrón de inyección de dependencias. Lo cual provoco una demostración de las capacidades de Windsor para soportar AOP.

Referencias:

“In-flght” profiling with AOP
Aspect# Integration Facility
Castle
Windsor AOP – Policy Injection Application Block – Best Way to Use Windsor AOP?
Building the Policy Injection in 40 Minutes with Windsor
Castle Windsor AOP – Dependency Injection and Aspect-Oriented Programming – Policy Injection Application Block
Policy Injection Application Block Example
ObjectBuilder is Getting Some Love for the CodePlex Container
.NET Community Downloads and Sample Code

Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.Surge entonces la necesidad d…

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.

Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

Continue reading “Generación automática de código”

Comparación de Java y C#

Hace algunos años , en un lugar de cuyo nombre no quiero acordarme, se discutía el plan quinquenal del programa académicos en tecnologí­a de información. Los administradores del grupo, siguiendo linea del jefe divisional, decidieron normalizar el…

Hace algunos años , en un lugar de cuyo nombre no quiero acordarme, se discutía el plan quinquenal del programa académicos en tecnologí­a de información. Los administradores del grupo, siguiendo linea del jefe divisional, decidieron normalizar el uso de Java para toda la curricula departamental. Algunos de los profesores expresamos tibias dudas sobre al asunto, pero no hubo realmente opiniones en contra.

A mi el incidente me recordó la tendencia histórica de los ejércitos del mundo a preparase para la guerra anterior sin comprender que el entorno tecnológico y social hacen inoperantes e irrelevantes enfoques que en el pasado hubieran sido determinativos e innovadores. La linea Magniot de los francés como ejemplo concreto.

Aunque Microsoft es más fiero como monopolio que como motor tecnológico, tiene el suficiente peso económico y social para absorber el mejor talento del mundo y el Sr. Puertas ha mostrado saber a donde va el puck.

Java sigue teniendo su lugar como herramienta de desarrollo inter-plataforma pero hay evidencias de que su mejor momento tal vez ya paso. Microsoft tiró el guante blanco al implementar la aplicación de referencia J2EE, PetShop, en .Net y obtuvo mejores números, tanto en lineas de código como en rendimiento. Cada vez que Java levantaba el guante, la evidencia era más contundente: .Net permite desarrollos en menos tiempo y con mejor rendimiento que J2EE.

En el mismo foro de desarrolladores de Java de Sun el consenso en el tema de manejo de genéricos fue que la implementación de C# es superior a la de Java.

Aunque hay diferencias de implementación, Java y C#, tienen puntos en común. Despues de todo, C# es la respuesta de Microsoft a Java. El articulo C# and Java: Comparing Programming Languages presenta una comparación detallada.

Un punto en común entre Java y C# es que no manejan herencia multiple y promueven el uso de interfaces para propositos equivalentes.

El sitio Desarrollo Profesional de Aplicaciones tiene bastante material didactico sobre .Net en español.

Programación orientada a aspectos

Tal vez sea porque estamos a principios de siglo o simplemente un espejismo pero pareciera que estamos en los albores de un cambio paradigmático en el desarrollo de software post orientación a objetos.Uno de los ideales del desarrollo de software es …

Tal vez sea porque estamos a principios de siglo o simplemente un espejismo pero pareciera que estamos en los albores de un cambio paradigmático en el desarrollo de software post orientación a objetos.

Uno de los ideales del desarrollo de software es la capacidad de modificar el funcionamiento de un sistema sin tocar una línea de código. Algunos enfoques en este sentido es inyección de dependencias y programación orientada a aspectos (AOP).

David Hayden en su bitácora presenta un ejemplo, en el contexto de la librería empresarial del grupo de patrones y practicas de Microsoft, del uso del bloque de aplicación de inyección de políticas para guardar registros de llamadas a métodos y se quejaba de que la librería en realidad no soporta el patrón de inyección de dependencias. Lo cual provoco una demostración de las capacidades de Windsor para soportar AOP.

Referencias:

“In-flght” profiling with AOP

Aspect# Integration Facility

Castle

Windsor AOP – Policy Injection Application Block – Best Way to Use Windsor AOP?

Building the Policy Injection in 40 Minutes with Windsor

Castle Windsor AOP – Dependency Injection and Aspect-Oriented Programming – Policy Injection Application Block

Policy Injection Application Block Example

ObjectBuilder is Getting Some Love for the CodePlex Container

.NET Community Downloads and Sample Code