Archive for the ‘ .Net ’ Category

Servicios REST con .Net y Entity Framework


Iniciando en este tema hace un par de meses me surgió la necesidad de crear un servicio Rest desde .Net, debido a que ya tenía la base de datos creada solo necesitaba publicar rápidamente un servicio Rest que recibiría un paráametro, asi que decidí crear un Modelo de Entity Framework y publicar directamente sin mayor esfuerzo.

Aqui les dejaré mi experiencia y la forma que encontré en mis busquedas en internet para resolver los inconvenientes que encontré, tarde casi 2 horas en publicar el servicio REST sin problemas, ahora bien despues de realizarlo y haber realizado esto hoy en unos 15 mins ya logro publicar un servicio REST fácilmente.

Antes que nada debemos tener nuestra base creada, se recomienda no utilizar un modelo directamente ya que estariamos exponiendo nuestra base directamente, es recomendable por buenas practicas crear entidades POCO (Ver mi post al respecto). Pero en mi caso logre publicar directamente el modelo Entity Framework esto con el fin de no crear una clase adicional y perdermas tiempo.

Aqui les dejo el paso a paso para crear un servicio Rest utilizando un modelo de Entity Framework. Nota: Si no quieres ver al paso a paso puedes bajarte el ejemplo de la aplicación del paso a paso aqui.

1) Crear una aplicación web en .Net

Seguir leyendo

¿Que es una entidad POCO?


Una entidad POCO es un objeto que no debe de tener asociado ningún framework que complique el uso de la clase, en pocas palabras no debe de ser una clase de un ORM, como lo es Entity Framework, NHibernate, XPO de DevExpress o algo similar.

Este tipo de objeto dbe de ser simple sus siglas en ingles Plain Old CLR Object, término que no se acuño en el ambito de .Net, originalmente este termino fue creado por Martin Fowler en el año 2000 para Java ahi las entidades se llaman POJO(Plain Old Java Object) y despues fue creado el término para .Net

Debido a la simplicidad o plano(plain) que debe ser este tipo de objeto es que no debe de depender o estar asociado a un framework específico. Hablando de arquitectura de software no debemos confundirlo con los DTOs(Data Transfer Object) que como su nombre lo dice es un objeto para transferir datos, normalmente una entidad POCO puede ser utilizada para comunicar las diversas capas de un sistema y un DTO para transferir a otros sistemas atraves de servicios web, rest, etc.

Entonces un POCO puede tener comportamiento y un DTO no, a comportamiento me refiero a ciertos calculos, como por ejemplo en una entidad Persona que tiene una propiedad FechaDeNacimiento puede tener una propiedad de solo lectura Edad la cual es calculada a partir de la FechaDeNacimiento y un DTO debería tener la propiedad Edad ya calculada.

Espero que esta breve explicación les sirva.

Saludos

«El fracaso tiene mil excusas, el éxito no requiere explicación»

«Que el Señor te bendiga y te guarde, te muestre su rostro y tenga misericordia de ti, te mire benignamente y te conceda la paz, que el Señor te bendiga hermano»

¿ASP Net MVC es el futuro?


Hace un par de años escribí sobre MVC todo esto basado en lo que aprendí investigando y probando la tecnología, recientemente me inicie en el mundo de MVC de manera formal, ya que nunca antes había tenido la oportunidad de desarrollar en un proyecto que utilizara esa arquitectura.

Al principio estaba entusiasmado por terminar de aprender una de las tecnologías que se ofrecen con .Net Framework ya que no había tenido la oportunidad de utilizarlo formalmente, únicamente lo había hecho como auto-aprendizaje, y la verdad es que en el fondo no cambio mucho mi percepción que tuve inicialmente al conocer MVC.

Mi percepción de primer contacto con MVC fue que muchas cosas volvían al pasado, esto lo pueden entender los que han desarrollado ASP puro, cuando estaba en auge Visual Basic 6.0 e Interdev con lo cual uno podía programar paginas ASP y uno tenía el control total que se escribiría en HTML procesado con tags incrustados(embebidos) con código VB6 en el HTML. Esto ofrecía muchas facilidades pero a la vez también ofrecía muchos peligros en la forma de hacer código, podía volverse difícil el mantenimiento del código haciendo uso de algo conocido como código espagueti.

En cuanto al rendimiento y pruebas unitarias con MVC es lo mejor que puedo rescatar del uso de esta tecnología, ya que realizar las pruebas unitarias es mucho mas fácil y el rendimiento mejora sustancialmente, aunque a mi juicio desarrollando con buenas practicas con ASP Net Web Forms y AJAX pueden desarrollarse sitios livianos, pero se complican un poco las pruebas unitarias del FrontEnd.

Espero publicar en estos días un tutorial sobre el uso de MVC, gracias y espero sus comentarios al respecto.

Elmer Carías

Que el Señor te bendiga y te guarde, te muestre su rostro y tenga misericordia de ti, te mire benignamente y te conceda la Paz, que el Señor te bendiga hermano – Paz y Bien.

¿Que plantilla de TFS utilizar?


Si estas leyendo esta entrada es porque tienes la incognita de cual plantilla que provee Visual Studio es la que mas se adecua a tus necesidades.

Pues te cuento que no hay una receta para decidir cual utilizar, pero dependiendo el escenario que tengas trataré de ejemplificar cada opción para que, si así lo deseas, tomes en cuenta mis opiniones.

Antes que nada hay que resaltar que lo que Microsoft propone no lo es todo, ya que Microsoft ha definido una plantilla para desarrollo ágil y una plantilla para desarrollo con metodologías mas robustas, adicionalmente como la fiebre es el uso de Scrum, entonces a traves de la comunidadd y varios personajes de Microsoft se realizo la plantilla para Scrum.

Pero la pregunta de rigor es: ¿y en que me ayuda una plantilla de proceso?

Pues a mi entender la plantilla no solo la tenemos que ver como algo que me obligará a realizar determinados documentos o artefactos para apoyar la administración del ciclo de vida de una aplicación(ALM por sus siglas en ingles), sino que ademas de definir ciertas reglas para documentar el proceso de desarrollo de sistemas, tambien nos ayuda a no olvidarnos de lo mínimo necesario a documentar, eso con respecto a la documentación, pero ¿será que eso es suficiente?, pues la respuesta es «si» desde un punto de vista no tan actualizado …. pero a mi juicio el desarrollo de software no solo es documentar y documentar, todo tiene un propósito y para el caso el tener una plantilla determinada me ayudará a poder tener estadisticas con el tiempo y tomar las desiciones mas acertadas en el momento adecuado.
Ademas de ayudarnos a madurar con el tiempo de cual es la mejor forma de documentar, el que, como y la frecuencia de documentar, eso al final nos hará poco a poco en buenos referentes no solo en nuestro lugar de trabajo sino que tambien en el ambiente profesional.

Antes de entrar en mataria definamos que es un Equipo de Desarrollo para los escenarios planteados, entendamos todos los roles posibles desde analista, programador, probador, coordinador de proyecto, administrador de base de datos(DBA), etc. Un Equipo de desarrollo pequeño normalmente no tiene definidos roles muy definidos, todos hacen de todo, y no existen especialistas.

Pero entremos en materia y comparemos los escenarios posibles para tomar una decisión:

1) El equipo de desarrollo es pequeño(de 2 a 5 personas) y no tiene una metodología adoptada ni un estandar definido de como desarrollar una aplicación.

2) El equipo de desarrollo es pequeño y se ha definido una metodología y si se tienen definidos varios roles como DBA, Analista-Programador, Arquitecto de Software, Gerente de Proyecto, aunque una persona puede cubrir mas de un rol a la vez.

3) Son varios equipos de desarrollo por Proyecto con una metodología formal(RUP, CMMI, SDLC,etc) o su empresa/organización/institución tiene bien definidos los roles y posiblemente unidades por Rol, como Unidad de Programación, Unidad de Análisis de Sistemas, Unidad de Pruebas o Calidad de Software, etc.

Plantillas de Proceso en TFS:

a) Visual Studio Scrum 2.0: Utilizar si se tiene el escenario 2 y si la metodología a utilizar es Scrum.

b) MSF for Agile v6.0: Utilizar si se tiene el escenario 1 o 2, para el caso del escenario 2 solamente si la metodología no es Scrum.

c) MSF for CMMI v6.0: Utilizar si se tiene el escenario 3.

No es así de simple en la Practica ya que si te encuentras en el escenario 1 pero se tiene pensado adoptar una metodología en particular, sería mas saludable primero definir que tipo de metodología se utilizará y cual se adaptará mejor a tu lugar de trabajo y basado en eso tomar la desición de cual Plantilla de Proceso utilizar.

Si quieres ver un comparativo de lo que incluye cada Plantilla de Proceso ve al sitio de Microsoft aqui.

Atte. Elmer Carías

«El Señor te bendiga y te guarde, te muestre su rostro y tenga misericordia de ti, te mire benignamente y te conceda la paz, que el Señor te bendiga hermano», Paz y Bien

Como crear un Proyecto de Equipo(Team Project)


Como parte de la serie de publicaciones sobre Team Foundation Server en este les comparto el paso a paso de como crear un Proyecto de Equipo(Team Project). Para ver la serie completa haga clic aqui.

1) Abrir el Visual Studio 2010

2) Conectarse al Team Project Collection deseado, para el caso utilizaremos el de ejemplo TeamProjectCollectionTest. Esto se hace desde la ventana Team Explorer del Visual Studio. Nota: Esto solo se realiza la primera vez, ya que despues de conectado a un Team Project Collection la siguiente vez al abrir el Visual Studio automaticamente se conectará a la Colección.

Dar clic en el botón Connect to Team Project

Seguir leyendo