Este es mi primer post en la comunidad, a pesar de que llevo ya 1 año desarrollando con CSLA no me habia dado el tiempo de compatir mi experiencia con este formidable framework. Por el momento les platico que va al momento y me presento.

Soy Mexicano de nacimiento, originario de Jalisco. Estudie ingenieria quimica y recien me gradue en este año pero comence a programar desde hace 7 años con Pascal, segui con C, C++, VB6, VB.NET y ahora adoro C#, ya no lo cambio al menos que realmente requiera de la potencia de C. He desarrollado un par de proyectos y a mediados de este año comence con un wrapper para visualizar pdf's con C# usando xpdf y mupdf, les dejo el link por si les interesa ;-) http://www.codeproject.com/KB/files/xpdf_csharp.aspx.

Comence en noviembre del 2008 con CSLA .NET 3.0, y usando como base las clases de CslaDBGenerator escribi mi propio generador para poder adaptarme a mis practicas de programación y a lo que crei que seria necesario en ese entonces, ahora he visto que mi generador no va del todo bien pero de cualquier modo les aviso cuando lo tenga en code google para que hagan sus comentarios y tal vez participemos en mejorarlo, pues no existe ninguna version hispana o al menos que yo conozca para generar codigo con CSLA .NET 3.6.2.

Uno de los problemas con los que estoy atorado ahorita es tal vez por una aferración, quiero automatizar el manejo de permisos con SQL Server, es decir; si tengo un usuario que no permita escribir la propiedad PurchaseDetail.ItemPrice, por ejemplo, quiero que CSLA me cargue automaticamente el rol y el permiso sin tener que especificarlo por codigo en el objeto, alguien ha pensado en esto y tiene idea de como resolverlo?.

Al momento es todo, me despido y a seguir con CSLA :-). Apoyemos esta comunidad que CSLA lo tenemos muy abandonado en México, no sé en otros paises de latinoamerica como les va.

Saludos!

Primero que nada este post es para resolver muchas de las dudas que me han preguntado para poder crear el instalador de los templates de CSLA.NET, al principio tuve un sin fin de problemas y no podia resolverlo, pero ahora puedo decir que lo logré.

El primer paso es bajar todos los fuentes de la última versión de CSLA.NET desde la página oficial:

• Csla Framework
• Csla Test
• Csla Silverlight
• Csla Silverlight Test

La estructura de directorios (ya descomprimidos) debería quedar así:

Lo bastante sencillo es compilar la solucion Csla, lo segundo es abrir la solución que lleva por nombre Csla-Build.

Obviamente que para que no nos salgan errores al momento de abrir esta solución debemos tener instalado lo siguiente:

• Visual Studio 2008 Professional o Superior
• Visual Studio 2008 SP1
  
• Microsoft Silverlight 3 SDK
• Microsoft Silverlight 3 Visual Studio Tools
• Microsoft Windows PowerShell 1.0

Si tienen problemas para instalar estos pre-requisitos les recomiendo bajar todos los componentes en el mismo idioma e instalarlos en el orden anteriormente descrito, ojo que Windows 7 ya viene con Windows PowerShell.

Ahora, CSLA.NET viene con un script de Windows PowerShell con extensión ps1, que se ejecuta al tratar de compilar el proyecto Setup dentro de la solución, y esto lo podremos comprobar de manera muy sencilla ya que si seleccionamos el proyecto y presionamos F4 (Propiedades) nos podremos fijar que en la propiedad PreBuildEvent encontrarán el siguiente texto:

Pero lo más problable es que les salga un error desconocido, y lo que es peor es que aquí empiecen los dolores de cabeza.

Este error se debe a que se trata de ejecutar un script de Windows PowerShell, pero éste no puede ser ejecutado por un tema de políticas de ejecución, para esto es simple arreglarlo.

Asi que iremos a la consola de Windows PowerShell y escribiremos el siguiente comando:

Set-ExecutionPolicy

Luego el sistema preguntará por el tipo de politica de ejecución y escribiremos Unrestricted, tal como está, lógicamente que Windows nos advertirá que si cambiamos las políticas de ejecución sería un riesgo de seguridad (por los virus), pero no se asusten, esto solo lo haremos con el fin de compilar la solución.

Si todo sale bien y compilan la solución verán que el script porfin se ejecutará sin problemas, este script lo que hace es comprimir todos los Snippets, Templates y demás archivos que luego se ejecutarán cuando termine la fase de instalacion.

Ahora nuevamente ejecutamos Set-ExecutionPolicy en la consola de Windows PowerShell y cuando nos pregunte que tipo de política colocamos le indicamos Default.

Ahora si podremos ejecutar el paquete MSI compilado y eso sería todo para empezar a Desarrollar con CSLA.NET.

Espero que les sirva.

Ultimamente he escuchado muchisimos comentarios acerca del lenguaje de programación que se debe usar para programar en .NET.
Pues bueno he llegado a la conclusion que ningun lenguaje es mejor que el otro, quizas muchos no esten de acuerdo conmigo, pero yo creo que como una vez dijo Microsoft todos los lenguajes se basan en el .NET Framework, que son los compiladores de cada lenguaje los encargados de realizar la tarea de traducir el código escrito a código MSIL.

Yo vengo programando en Visual Basic desde 1999 y la verdad es que me gustó mucho el lenguaje por ser sencillo de comprender, con el tiempo me di cuenta que dicho lenguaje recibia muchísimas críticas por no ser orientado a objetos (VB6) pero con la llegada de .NET eso cambió.
Aunque aún no logro entender porque Microsoft se empeña en seguir soportando estereotipos y formas de programación de VB6 en .NET aún, como por ejemplo el hecho de hacer Late Binding (Enlace tardío) que permite llamar a un método, funcíón o propiedad de un objeto que no esté explicitamente declarado.

Esa es una de las tantas malas prácticas por las cuales es criticado Visual Basic, sin contar con las palabras clave como "On Error Goto" y muchas más. Todo esto se puede resolver haciendo lo correcto como:

1. Configurar Visual Studio para que siempre exiga la declaración de Variables y que ya no use el Late Binding, esto es posible desde el menú Tools -> Options -> Projects and Solutions -> VB Defaults -> colocar en "ON" a Option Explicit (Forzar declaración de Variables), Option Strict (Impedir el uso de late binding y conversiones implícitas),

2. Evitar el uso de tipos de datos propios de Visual Basic para declarar propiedades o variables como Short, Integer, Long, usar Int16, Int32, Int64 respectivamente. Siempre recomiendo usar los tipos de datos nativos del propio .NET Framework.

3. Al igual ocurre al momento de convertir de un tipo a otro, por ejemplo hay que evitar el uso de CInt, CDouble, CDate, en vez de eso usar la clase Convert, para poder usar funciones como Convert.ToInt32, Convert.ToDouble, Convert.ToDate, etc.

4. Cuando se creen instancias de nuevos Objetos acostumbrarse a abrir y cerrar los paréntesis de los costructores como Dim objClase As Clase = New Clase(). Ya que normalmente VB no lo obliga lo cual en C# no es así.

5. Evitar el uso de MsgBox en WinForms, en vez de eso usar MessageBox.Show.

6. Evitar el uso de las importaciones a nivel de proyecto excesivas (yo me conformo con lo que Visual Studio me coloca por defecto).

7. Usar siempre bloques Try...Catch en vez de On Error Goto.

Siguiendo estas indicaciones estaríamos programando como cualquier otro lenguaje dentro de .NET Framework, así cuando queramos leer un código hecho en C# no nos costará nada comprenderlo, pues la única variedad es la sintaxis de cada uno.

En conclusión, desde mi punto de vista personal, no existe mejor lenguaje que otro en el mundo de Microsoft .NET Framework, pues todos al final compilan al mismo MSIL, pero eso tampoco significa que nunca debamos programar en otro lenguaje, si bien cada uno tiene sus ventajas y desventajas, son tan sólo "ayudas" que nos permiten desarrollar más rapido, pero al final el rendimiento es el mismo.

Por ejemplo, algo que me encanta de C# y que no tiene Visual Basic es:

1. Code Snippets incluidos en el IntelliSense.
2. Refactorización de miembros.
3. Permitir quitar el uso de Usings (Imports en VB) innecesarios.
4. No tener que escribir _ (underline) para continuar con una instrucción (aunq esto en VB 10.0 ya es posible)
5. Te muestra advertencias cuando colocas condiciones en un bloque de código que nunca se ejecutará.
6. Crear namespace automáticamente si estructuras tus clases en carpetas.

Y así como estas (que hay muchas más que no he mencionado) Visual Basic también tiene cosas que no tiene C#:

1. Importaciones (usings en C#) a nivel de proyecto. (Aunque en exceso es lo peor)
2. Quitar referencias sin utilizar (ensamblados a los que no necesariamente usas en tu proyecto)
3. Mayor variedad de Code Snippets por defecto que C# (Microsoft lo hace para que uno se guie de estos ejemplos)
4. Namespace My en los proyectos, que encierran bastantes funciones útiles para el resto de la aplicación (lamentablemente usa estereotipos propios de Visual Basic)

Pero por lo demás se puede seguir diciendo que estas comparaciones son meramente "features" de cada lenguaje que a mi parecer no tienen nada que ver con el rendimiento de la aplicación, esto quiere decir que si programas en Visual Basic, siguiendo las recomendaciones que te indico, tendrás tanto rendimiento en las aplicaciones como buenas prácticas de desarrollo y "matando" por fin de una vez el viejo estillo de VB6.

Hace poco más de un año se grabó un video en el que se explica a más detalle estas diferencias Clic aquí

Espero sus comentarios.

Nuevos Blogs Para la Comunidad:

En un esfuerzo de la comunidad, hemos obtenido el apoyo económico de CODESOL organización que ha donado la compra del componente IDOBlog para nuestros CMS basado en Joomla.

IMPORTANTE:

En adelante todos los miembros registrados DEBEN SENTIRSE LIBRES Y CON TODA LA CONFIANZA de registrar sus experiencias a traves del Blog de la comunidad, el cual esta estructurado por cada perfil de usuario, de tal forma que puedes participar y ser identificado como Editor en la comunidad.

1. Registrate como usuario/miembro de la comunidad.
2. En el módulo ubicado al lado izquierdo del portal, haz un clic en Nueva entrada y listo.
3. Registra tus experiencia con .NET y lo principal las relacionadas con CSLA .NET.

Reconocimiento de Rockford Lothka, creador y fundador del framework

Es bueno recordarles a todos los miembros que somos usuarios de CSLA .NET, que somos una comunidad hispana oficialmente reconocida por Rockford Lothka.

Para muestra dejo dos enlaces donde pueden leer y ver el reconocimiento a nuestro trabajo en beneficio del framework como alternativa abierta y libre para el beneficio de todos nosotros.

• FAQ Oficial De CSLA .NET

• Enlace en el portal Oficial De CSLA .NET

Muchas veces nos ha pasado tenemos el gran problema que para depurar nuestras aplicaciones ASP.NET (Mobile, Web, WAP) nos sale un error como indica aqui Lhotka.

El problema aqui es el IIS incorporado con Visual Studio, para solucionarlo hacer lo siguiente:

Paso 1:

Creamos un directorio Virtual que apunte a la carpeta de trabajo que estamos trabajando

para averiguarlo, seleccionen el Proyecto Web en Visual Studio y presionen la tecla F4 para

ver la ruta.

Paso 2: Configurar las propiedades del Directorio Virtual del IIS. En la ficha Seguridad de Directorios,

fijarse que esté marcada la opción de Autenticación Windows .

Paso 3: Asegurarse que su directorio Virtual usará ASP.NET

Paso 4: Final
En las propiedades del Proyecto Web asegurarse que estén usando un Servidor Web

Personalizado (en otras palabras IIS)

Esto nos asegurará que podamos usar IIS para depurar nuestras Aplicaciones ASP.NET sobre el servidor

IIS usando Visual Studio (2005 o 2008) ya que éste es mucho mejor que el que tiene Visual Studio

integrado.

CSLA .NET es uno de los frameworks que actualmente utilizo y son muchas las veces que me han preguntado ¿Porqué deberíamos usar CSLA .NET en nuestros proyectos?. Bueno en este primer post de mi blog trataré de explicar mi punto de vista profesional, el porqué y cuando deberías usar el framework, algunos recursos y como iré aprovechando este blog para publicar más acerca de este framework para todos los que desean conocer un poco más de el.

NOTA: Esta es una opinión y apreciación personal y profesional, puede ó no estar mucha gente de acuerdo, así que no reniegues. Te invito a dejar tus comentarios y visitar la comunidad.

¿Qué es CSLA .NET?

Para empezar es necesario tener claro que es CSLA .NET para esto cito la definición del creador y fundador del framework Rockford Lhotka.

¿Qué significa esto?, pues que CSLA .NET esta definido, diseñado y planificado apara concentrarse en la capa de negocios. Ten en cuenta que no esta estructurado de gran forma para orientarse a características especificas de la capa de presentación y la capa de acceso a datos.

En el mercado actual existen diferentes frameworks dedicados a persistencia de datos como NHibernate, a capa de presentación como SCSF, PRISM V2,  muchas otras opciones disponibles en la red con las mejores prácticas de desarrollo propuestas por las grandes empresas de software y comunidad de desarrolladores.

NOTA: No comparto que CSLA .NET no tenga buenas practicas de desarrollo, en su contexto para mi las tiene y es lo mejor que he encontrado, probado e implementado.

Firmo Esto:

Siempre seguiré pensando que se debe aplicar el uso de herramientas en base al contexto en que nos encontramos y sin discriminarlas por ninguna ideología de software.

Mi Participación En ALT .NET Hispano

Mi relación con ALT .NET Hispano empezó a ser más cercana desde la VAN dedicada a CSLA .NET, en adelante mi participación fue más comprometida por mi amistad con mi buen amigo Jorge Gamba. En aquella oportunidad tuvimos la oportunidad de participar quien escribe (Comunidad Hispana CSLA .NET) y Andrés Villanueva (Team Leader CSLAGenerator). Aquel día tuvimos diferentes opiniones y puntos de vistas de diferentes expertos, en especial debo destacar a Fabio Maulo (Team Leader NHIbernate).

Mi Opinión Personal Sobre La Reunión ALT .NET Café Del 29 De Agosto

Tema: WPF + NHibernate

Presentadores: Fabio Maulo y José Romanielo

Referencias De La Demostración:

Part I: Introducing NHiberate and WPF: The ChinookMediaManager
Part II: Nhibernate and WPF: The core
Part III: Nhibernate and WPF: Models concept
Part IV: Nhibernate and WPF: ViewModels and Views

“Antes de todo debo agradecer  a Fabio y José por la iniciativa a compartir sus conocimientos de forma desinteresada y en el bien de la comunidad”.

Primero pienso que es bueno entender muy bien (y en eso estoy día a día cuando el tiempo lo permite) conceptos como TDD, DDD y BDD, como y en que escenarios aplicarlos realmente en base a las variables que podemos encontrar según nuestro contexto. Es un tema del cual aún no me siento preparado como para hacer una comparativa, pero espero pronto postear de acuerdo a mis avances en mi aprendizaje, uso y experiencia aplicando alguno en mi vida profesional.

Técnicamente la VAN me pareció buena, los conocimientos expuestos por José Romanielo sumados a la sapiencia de Fabio Maulo desde mi punto de vista formaron un dúo perfecto.

Pienso que para todos los que nos conectamos a la reunión las horas invertidas fueron muy provechosas y ricas técnicamente. Pero también pienso que fue más provechosa para los desarrolladores que prefieren y les favorece el tener control total de todos los componentes de la arquitectura lógica para obtener un resultado.

ADVERTENCIA: En esta entrada vamos a ver el desarrollo de una pequeña aplicación usando CSLA .NET 3.0.5 de forma tradicional hasta antes del último libro  Expert Business Objects C# 2008 publicado por Rocky, ten en cuenta que al tratarse de una forma tradicional de desarrollo en CSLA para las versiones 3.0.5 ó inferiores, la aplicación es  muy acoplada y dependiente en su totalidad del framework.  El objetivo de esta entrada es mostrar el desarrollo tradicional con CSLA y en otra próxima entrada utilizar la última versión del framework y permitir un mayor desacoplamiento en base a responsabilidades.

La próxima entrada en este blog para la demo CubiDemo, contemplará:

• CSLA 3.8 (uso de ObjectFactory, Padres, Hijos, Nietos, Transacciones)
• Enterprise Library (DAAB).
• LinqToCSLA
• Entity Framework, mientras empiezo mi camino de aprendizaje de NHibernate
• SCSF ó ASP .NET MVC.

Descarga de Fuente: Repositorio de demostraciones CSLA .NET Hispano

Requerimiento Funcional De La Aplicación:

Hace unos días un amigo necesitaba mostrar el resultado de un experimento que consiste en obtener el cubicaje (peso, largo, alto, ancho y calcular el volumen) de carga suelta (mercadería pequeña) a través de un prototipo de balanza que tuvo una inversión de alrededor de $ 4,000. Para esto nos juntamos especialistas en mecatrónica, electrónica y sistemas, con el objetivo de diseñar la interface de hardware en base a sensores de luz y un software capaz de comunicarse con el prototipo de balanza mediante comunicación serial y obtener la trama definida por el dispositivo.

Pues bueno, mi participación fue en el desarrollo de la pequeña aplicación parte de la prueba de concepto que tenía como requisitos lo siguiente:

1. Registro simple de artículos y familias, solo son necesarios atributos básicos para poder realizar la prueba de concepto, no se necesita especificar conceptos de apilabilidad, perfumancia, paletizado, etc.
2. La aplicación debe ser capaz de recibir la trama desde el dispositivo a través de puerto serial y/ó también debe ser capaz de interpretar un archivo Excel y de texto con la información de pesos que será dejada por el dispositivo en un directorio especifico.
3. Permitir la consulta de artículos por familia, un gráfico de barras que muestra la cantidad de artículos registrados por familia y un reporte simple que muestre todas las pesadas.

En conjunto con los especialistas se definió la siguiente pantalla:

Hoy en día contamos con diversas tecnologías Microsoft para crear soluciones y/ó productos de alto nivel. Algunas de estas son: Windows Forms, ASP .NET, WPF, Silverlight, WCF, WF.

Ver Detalles De Tecnologías Microsoft.

Herramientas Propuestas Formalmente Por Microsoft: Para trabajar en base a las mejores prácticas de desarrollo Microsoft inició el proyecto Microsoft Patterns & Practices equipo que tiene como principal objetivo ayudar a los equipos de desarrollo de software a lograr el éxito con la plataforma de aplicaciones de Microsoft.

Microsoft es el sponsor por lo que es claro que se trata de un aporte a la comunidad, pero con una clara estrategia de posicionamiento de mercado, lo cual es muy válido al tratarse de una empresa comercial.

Para tener más detalles del trabajo general de P&P podemos ver Microsoft Application Architecture Guide

Entre sus frameworks para optimizar aplicaciones tenemos disponibles:

· Composite Application Guidance for WPF and Silverlight

· Smart Client Software Factory

· Web Client Software Factory

· Mobile Client Software Factory

· ASP .NET MVC

La principal idea es facilitarnos a los desarrollados la mayor transparencia posible sobre las complejidades que implica un desarrollo con modelos como MVC, MVP y MVVM a través de paquetes compactos y que tienen como fin elevar nuestra productividad y eficacia al momento de crear software.

Para los aspectos (AOP) de arquitectura P&P nos ofrece el famoso Microsoft Enterprise Library y para la unificación y gestión de los frameworks en Visual Studio tenemos el no menos famoso Guidance Automation Extensions and Guidance Automation Toolkit.

NOTA: Antes de continuar con esta entrada, te recomendamos leer el concepto de Seguridad Basada en Funciones y Objetos Principal e Identity.

CSLA .NET cuenta con un mecanismo de gestión automatizada para autenticación y autorización en sus objetos de negocio.

Podemos ubicar la región Authorization Rules en la aplicación de ejemplo ProjectTracker, el fragmento de código es el siguiente:

   #region  Authorization Rules

    protected override void AddAuthorizationRules()
    {
      // add AuthorizationRules here
      AuthorizationRules.AllowWrite(NameProperty, "ProjectManager");
      AuthorizationRules.AllowWrite(StartedProperty, "ProjectManager");
      AuthorizationRules.AllowWrite(EndedProperty, "ProjectManager");
      AuthorizationRules.AllowWrite(DescriptionProperty, "ProjectManager");
    }

    protected static void AddObjectAuthorizationRules()
    {
      // add object-level authorization rules here
      AuthorizationRules.AllowCreate(typeof(Project), "ProjectManager");
      AuthorizationRules.AllowEdit(typeof(Project), "ProjectManager");
      AuthorizationRules.AllowDelete(typeof(Project), "ProjectManager");
      AuthorizationRules.AllowDelete(typeof(Project), "Administrator");
    }

    #endregion

Si tienes un poco de tiempo, te recomiendo leer la Overview of CSLA .NET 3.6 for Windows and SilverLight. Ahora si tienes más tiempo y deseas complicarte un poquito la vida (no es el objetivo de esta entrada), puedes dirigirte al capítulo 12 del libro Expert Business Object C# 2008 ó leer en línea la versión para VB .NET gracias a Google eBook.

Como usuarios de CSLA .NET debemos entender que el framework nos da la posibilidad de pasar una matriz de roles para permitir la validación a nivel de propiedad ó objeto.

NOTA: Antes de leer esta entrada te recomiendo leer este artículo acerca de TDD, pruebas unitarias con NUnit y MockObjects.

Introducción Por Fabian Figueredo

Quizás en estos días estés escuchando el termino TDD (Desarrollo guiado por pruebas), estas pruebas de unidad nos ayudan a crear aplicaciones robustas y reducir la cantidad de errores.
Lo más llamativo de esta manera de programar es que las pruebas unitarias se realizan en primer lugar y luego el desarrollo consta en superar estas pruebas.

¿Que es una prueba de unidad o unit test?

Es una porción de código con la única función de realizar pruebas o testeos a métodos o clases.

NUnit Framework

Hay una herramienta muy poderosa y conocida por todos los desarrolladores llamada NUnit, este framework nos ayudará a crear nuestros proyectos unit test.

Fuente: Oberdata.

CSLA .NET y las Pruebas Unitarias:

Seguro muchos hemos trabajado con pruebas unitarias, particularmente no soy muy amigo de TDD, pero en ciertos escenarios es necesario, principalmente cuando el tiempo del proyecto no es muy corto y se prioriza la anticipación de posibles errores funcionales.

Bueno, ¿Qué pasa con CSLA .NET?, en realidad se pueden hacer desde siempre pruebas unitarias sin ningún problema, Rocky lo incluye en la descarga del framework, podemos encontrar las pruebas en la carpeta cslatest: