Devlixir.com : blog de desarrollo web en espanol, asp.net mvc nhibernate

Se Busca desarrollador .NET - Guayaquil, Ecuador

Javier Romero — Mon, 19 Oct 2009 15:52:00 GMT

La compañía para quien laboro: Image Tech, busca un desarrollador .NET para pertenecer a nuestro equipo de trabajo, en una relación a largo plazo. Estamos localizados en Guayaquil, Ecuador.

He aquí los requisitos.

Experiencia de mínimo 3 años manejando proyectos .NET.
Conocimientos y habilidades sólidas y comprobables en:
C#, ASP.NET, AJAX, JQuery, CSS, Sql, Web Services.
Excelente Manejjo de de Visual Studio (2005 +)
Pro-actividad, Trabajo en equipo, trabajo bajo presión.
Certificación MCP (Recomendable pero no indispensable)

Image Tech ofrece:

Pertenecer al grupo de vanguardia en desarrollo .NET en la región.
Oportunidades continuas de crecimiento y capacitación.
Excelente clima laboral
Estabilidad
Remuneración de acuerdo a la capacidad.

Si estás interesado en aplicar o conoces a alguien que lo quisiera estar, envía tu CV (sin foto) a trabajo@imaget.com con el asunto : DESARROLLADOR .NET hasta el día jueves 22 de Octubre.

IEnumerable a DataSet, Extension Method

Javier Romero — Thu, 25 Jun 2009 02:09:35 GMT

Mientras realizaba refactoring en el código base del framework de la compañía que laboro, me surgió la necesidad de transformar una lista genérica List<Objeto> en un DataSet. El código ha sido heredado desde hace algún tiempo y resultaba complicado modificar algunas collecciones customizadas que se realizaron para el proyecto.

Además las aplicaciones futuras necesitan la funcionalidad, bastante útil en tareas administrativas, de transformar una colección a DataSet. Pues encontré algunas fuentes interesantes de información: CodeProject presenta una alternativa bastante interesante, Keith Elder y Sunil Kumar Saini hacen algo similar y hasta StackOverflow está lleno de preguntas al respecto.

Pues yo me quedo con un artículo publicado por Ian Dikes, quien ha creado un método extendido para el objeto IEnumerable que nos permitirá transformar cualquier lista que implemente esta interfaz (IEnumerable) a DataSet.

El método es bastante simple y tomado de base de Keith Elder y su post: Obtener las propiedades y sus tipos, armar el dataset y popularlo para devolverlo luego.... Me tomaré la libertad de copiar el código para compartirlo con todos.

public static class CollectionExtensions
{
public static DataSet ToDataSet(this
IEnumerable collection, string dataTableName)
{
if (collection == null)
{
 throw new ArgumentNullException("collection");
}

if (string.IsNullOrEmpty(dataTableName))
{
 throw new ArgumentNullException("dataTableName");
}

DataSet data = new DataSet("NewDataSet");
data.Tables.Add(FillDataTable(dataTableName, collection));
return data;
}

private static DataTable FillDataTable(string tableName,
IEnumerable collection)
{
PropertyInfo[] properties = typeof(T).GetProperties();

DataTable dt = CreateDataTable(tableName,
collection, properties);

IEnumerator enumerator = collection.GetEnumerator();
while (enumerator.MoveNext())
{
 dt.Rows.Add(FillDataRow(dt.NewRow(),
enumerator.Current, properties));
}

return dt;
}

private static DataRow FillDataRow(DataRow dataRow,
T item, PropertyInfo[] properties)
{
foreach (PropertyInfo property in properties)
{
 dataRow[property.Name.ToString()] = property.GetValue(item, null);
}

return dataRow;
}

private static DataTable CreateDataTable(string tableName,
IEnumerable collection, PropertyInfo[] properties)
{
DataTable dt = new DataTable(tableName);

foreach (PropertyInfo property in properties)
{
 dt.Columns.Add(property.Name.ToString());
}

return dt;
}  
}

Recibe el nombre de la tabla a crear, inclusive se podría modificar para incluir el nombre del DataSet, yo no lo necesitaba. Ahora solo basta invocar el método ToDataSet en cualquier objeto que implementa IEnumerable para obtener el DataSet.

Happy Coding

ASP.NET MVC: Trece preguntas básicas

Javier Romero — Tue, 05 May 2009 23:59:00 GMT

José Aguilar en Variable Not Found ha publicado un excelente artículo para quienes quieren conocer de forma general asp.net MVC o quienes aun necesitan algo más para decidirse por este framework para desarrollo de aplicaciones web.

Las 13 preguntas son:

   1. Empecemos desde el principio, ¿qué es MVC?
   2. ¿Qué ventajas tiene el uso del patrón MVC?
   3. ¿Qué es ASP.NET MVC framework?
   4. ¿Es el primer framework MVC creado para .NET?
   5. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?
   6. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?
   7. ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?
   8. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?
   9. ¿Se puede utilizar ASP.NET Ajax con el framework MVC?
10. ¿Se puede utilizar VB.NET con ASP.NET MVC?
11. ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework?
12. ¿Qué tipo de tecnologías puedo utilizar en las vistas?
13. ¿Es ASP.NET MVC framework software libre?

Excelente material de lectura, leélo aquí:

Variable Not Found: ASP.NET: trece preguntas básicas.

El Desarrollo Agil es más una cultura que un proceso.

Javier Romero — Tue, 28 Apr 2009 18:22:27 GMT

Del por qué tratar de ser "Agil" (Agile) como una cultura y no solamente un proceso implica resistencia y dificultad para enseñar y aprender la implementación del mismo.

Una cultura, no un proceso

Hemos venido trabajando junto con José y el equipo del comité de calidad y casi todos en la oficina durante meses, ayudándonos mutuamente para poder adoptar una metodología de desarrollo ágil. Ahora luego de tanto tiempo parece que al fin estamos en el camino de implementarlo. Pero el equipo, de forma lógica, y yo mismo me incluyo, no necesariamente está contento con lo que adoptar un proceso significa. El hecho de tantos informes, papeles, pasos a seguir, cambios en el camino, el hecho de hacer de nuestro proceso lo más flexible posible, pensando en la calidad como premisa y en los colaboradores (el equipo) como parte medular de todo el proceso... son conceptos nuevos que estamos tratando de adecuar a la "naturaleza" de nuestro negocio e interacción interna.

Alguna vez de dije a José:

"Al fin me dí cuenta... Debemos implementar una Cultura de Desarrollo Ágil, y no un proceso."

Para explicar mejor la situación comencemos con algunos ejemplos:

Desde la gerencia de proyectos
José, es responsable del manejo de proyectos, de la relación del proyecto con el cliente y por ende de la compañía. El debe lidiar con los requerimientos de los clientes, con los cambios durante el camino recorrido por el proyecto, de responder ante la gerencia por la efectividad y rentabilidad del proyecto; muchas veces sin importar las situaciones o cambios en este mismo trayecto. Pues José se ve obligado a implementar un proceso ágil, un proceso que le permita en base de la "confianza" en el equipo tomar decisiones en el camino sin que afecten al proyecto, pero teniendo evidencias de lo que estos cambios significan, he allí donde entra la "formalidad" de este proceso: reporte de tareas, horas trabajadas, reporte de costos. No se pueden tomar decisiones "ágiles" sin estos parámetros.

Desde el diseño de interfaces y Arquitectura
Wendy y Michael, son responsables de la experiencia de usuario, diseño de interfaz y de la interacción del usuario con esta interfaz. Ellos ponen un gran valor agregado a los requerimientos que los clientes nos hacen llegar. Transforman simples deseos, en productos reales y factibles. Se podría decir que este rol o grupo debería vivir dentro de una "cultura de diseño" la cual podría estar manejada por la subjetividad, percepción estética y funcional. Para el triunfo de la adopción "Agil" ellos no deben abandonar esta visión, es más el proceso propuesto asume este gran valor y lo mantiene junto con otros más de la cultura de diseño. Pero a la vez ellos adoptan valores que vienen con la cultura "Agil", como por ejemplo, el hecho de tener siempre un producto visible en cada etapa, en el seguimiento de cambios, en la facilidad de dar giros en el proceso de acuerdo a las necesidades. Así mismo implica muchas otras responsabilidades para el éxito del proceso: registro de actividades, evidencias de artefactos, etc. Recordemos: La gerencia o jefatura de Proyectos no puede tomar decisiones si no tiene "datos reales" en qué basarse.

Cultura es proceso

En alguna ocasión conversando con José, hablamos sobre cómo los cambios de implementación del proceso puedan ser hechos sin "desgracias". Es más con la perspectiva de poder agregar más miembros del equipo o inclusive nuevos equipos a nuestra organización, la tarea de propagar el proceso o la cultura nos llevaría a estrategias fluidas de comunicación constante dentro de los equipos, entre todos los equipos... Cada uno de los equipos y de las personas que los conforman poseen valores individuales que son válidos y se requiere mantenerlos en el proceso.. Cómo mantenemos estos valores dentro del proceso? . Pues convirtiendo estos valores en parte de la "cultura de la compañía". Esas cosas que la compañía (como ente comercial, como lugar de trabajo, como familia) valora ya desde ahora y desde siempre de todos... debemos hacerla parte del proceso.

De allí que pensando de forma sabia, la salida más obvia es:

"La Cultura es un proceso. Indentifiquemos nuestra cultura y la promovemos"

Tal vez esta afirmación no tenga sentido para ninguno... pero para mí si.

Veamos el proceso de vida basado en la cultura de nuestro país:

Ir a la escuela y estudiar lo mejor que se puede
Ir a una buena universidad
Casarse
Comprar una casa
Tener de 2 a 3 hijos
Ahorrar para la jubilación.
Tener tu propio negocio.
Te jubilas y te dedicas a molestar a tus hijos.
Te dedicas de viejo a consentir y malcriar a tus nietos.

Bueno sería lo ideal. Pero el asunto está en que cada proceso de vida cambia de acuerdo a la cultura, los gringos tendrán un proceso distintos, los hindúes otro, los chinos otros.

El punto está que dentro nuestra organización debemos encontrar nuestra cultura común la cual la incluimos dentro de lo "supuestamente rígido" del proceso. De manera que este proceso se entendible para todos dentro de la organización: "Dentro de nuestra cultura común".

No podemos escapar a nuestros valores, dentro del proceso

Estos valores de nuestra cultura organizacional forman constantes dentro de nuestro proceso llevándonos a realizar tareas basadas en estos valores, así no deberíamos tener situaciones como:

"Este no es mi problema, ese error está fuera de mi área de acción."
"No puedo cambiar esto, no quiero hacerlo."
Miedo al cambio.

No podemos cultivar valores de nuestra cultura que nos lleven a crear un proceso pobre, la actitud debe ser propensa al cambio y a los retos.

"Propaguemos nuestra cultura de desarrollo ágil, luego los procesos y técnicas."

Seamos partícipes cada día, de la propagación de esta cultura. Somos una comunidad de desarrollo web. Nuestra cultura es un nicho y podemos propagarla a través de:

Lenguaje
Tenemos nuestra jerga propia, heredada en el tiempo, saquemos lo mejor de ella.

Historias, héroes, mitos, leyendas y chistes
Tenemos historia de desarrollo dentro de la organización, anécdotas, chistes, historias difíciles de creer, cosas que alimentan nuestra vida de desarrollo.

Valores, normas, reglas, tabúes
No podemos ser ágiles sin valores, sin reglas, de los valores del manifiesto ágil tomaré 5, estas definiciones describen cuán importante es la cultura ágil. Como podemos ver tiene implicaciones dentro del proceso, pero no podemos decir exactamente en qué parte del proceso afecta.. porque enmarca a todo el proceso!.

Entrega continua de software realmente valioso.
Los requerimientos de cambios son bienvenidos.
Buscar la satisfacción del cliente lo más pronto posible y con entregas continuas y a tiempo.
Los encargados de negocios y los desarrolladores deben trabajar juntos "siempre".
Construyamos proyectos alrededor de motivar a las personas, a todas!.

Rituales, ritos, ceremonias y celebraciones
Las reuniones de los lunes, la planeación de proyecto, la presentación de diseño, la publicación en el servidor de pruebas o la celebración de un proyecto terminado a tiempo. No son excusas, son formas de incluir nuestra cultura en el proceso.

Tecnología, Artefactos, Entregables, reportes, etc
Finalmente, el proceso y la cultura ágil no es nada sin entregables, sin el registro de entregables, sin las evidencias de que la cultura influye "objetivamente", cuantitativamente en el engranaje de la organización. Si pensamos en trabajo manual, lógicamente tenemos un problema desde el principio. Pero tenemos herramientas que nos ayudarán a realizar esta tarea.

Y entonces Qué?

Si tomamos más en serio nuestra cultura dentro del proceso que estamos implementando y valoramos las cosas intrínsecas de nuestra organización, mejor estaremos aprendiendo y enseñando a ser ágiles. Ágiles en el desarrollo de software que es lo que nos interesa.

Kobe: Web 2.0 Service Development Resource Kit

Javier Romero — Thu, 16 Apr 2009 21:28:00 GMT

ACTUALIZADO: 17/04/2009

Tal como me imaginaba, Microsoft ha retirado la descarga de este KIT, con la finalidad de incorporar los comentarios de la comunidad de desarrollo. Hay muchas conversaciones y artículos sobre este tema, especialmente en twitter, pero también en el blog de Phil Haack, aparte Ayende ha posteado aproximadamente 7 artículos al respecto y Karl Seguin ha hecho lo mismo. Esperemos entonces que las "peores mejores prácticas" sean re-publicadas próximamente.

POST ORIGINAL

El proyecto Kobe contiene una serie de recursos para la planeación, arquitectura e implementación de aplicaciones Web 2.0 y servicios usando la plataforma de desarrollo de Microsoft: ASP.NET, ASP.NET MVC, MS SQL, etc. Orientado para quienes toman decisiones de tecnología, arquitectos de soluciones, jefes de desarrollo y desarrolladores en la comunidad creciente de "startups" o a nivel empresarial quienes desean aplicar, crear o soportar projectos sobre servicios/aplicaciones Web 2.0.

Este kit está disponible para descarga en MSDN y contiene:

Documentación
Walk-Trough
Proyecto de Muestra.
Presentaciones.
Videos

Lo bajaré y revisaré buscando situaciones interesantes y sobre todo observar que las "convenciones" y "estándares" que la comunidad ha establecido "de facto" hayan sido tomadas en cuenta.

Descárgalo en MSDN: http://msdn.microsoft.com/en-us/architecture/bb194897.aspx

Capítulo Gratis de Libro sobre ASP.NET MVC

Javier Romero — Wed, 15 Apr 2009 19:52:38 GMT

Lo leí en el feed de Tweeter de Elijah Manor, si no lo sigues... qué esperas?. Siempre publica links y recursos bien avanzados para desarrolladores.

Pues hoy, el anunció sobre un capítulo gratuito del libro ASP.NET MVC 1.0 Quickly escrito por Maaten Balliauw. Un muy interesante recurso para quienes quieren aprender ASP.NET de una forma mucho más ágil. En resumen un recorrido rápido por la arquitectura ASP.NET MVC, integración con AJAX y jQuery, Routing y Testing utilizando Mocking.

El capítulo gratis es el No. 2: "Your First ASP.NET MVC Application", explicando la plantilla de proyecto ASP.NET MVC dentro de Visual Studio. La construcción de una aplicación web simple y un recorrido rápido de algunos aspectos del framework ASP.NET MVC.

Si te resulta interesante, descarga el libro directamente desde aquí.

Principios de S.O.L.I.D

Javier Romero — Mon, 13 Apr 2009 14:09:00 GMT

A lo largo del camino de "aprender" todo lo involucrado al desarrollo web con Asp.net MVC, implementaremos muchos principios de programación a veces desconocidos para nosotros, o al menos "omitidos" en aras del tiempo, supuesta eficiencia o simplemente porque nos queremos ir por el camino fácil..

Pues un aspecto principal de esta ~~"nueva teoría"~~ a aprender son los principios S.O.L.I.D. que regirán de aquí en adelante todos los esfuerzos de diseño y codificación de las aplicaciones mvc que realicemos.

Qué es S.O.L.I.D.?

Es una colección de mejores prácticas y principios del diseño orientado a objetos que podemos aplicar a nuestros diseños para cumplir algunos objetivos como: loose-coupling, mayor mantenimiento del código, localización intiutiva de código, etc. S.O.L.I.D. es una abreviatura (acrónimo) para estos principios.

Estos principios fueron recogidos y compendiados en un trabajo escrito por Robert "Tio Bob" Martin (Uncle Bob Martin). Podemos encontrar más detalles de este trabajo en: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.

Vamos a dar un pequeño resumen sobre cada uno de estos principios, pero no iré a los detalles, para no cansar con mucho texto que leer, preferiblemente enlazaré artículos y webcasts que permitan de forma práctica comprender estos principios y aplicarlos de la forma más óptima y eficiente posible.

SRP: Single Responsibility Principle

NO DEBERÍA HABER MAS QUE UNA RAZÓN PARA QUE UNA CLASE CAMBIE.

En SRP una razón para cambiar es definida como una responsabilidad, por lo tanto es considerado como un estado. Si un objeto tiene más de una razón para cambiar, entonces tiene más de una responsabilidad lo cual es una violación a SRP.

Para entender este principio, mira este webcast de DimeCast.net:

Creating SOLID Code: Single Responsibility Principle (SRP).

Más detalles:

OCP: Open Closed Principle

LAS ENTIDADES DE SOFTWARE(CLASSES, MODULES, FUNCIONES, ETC), DEBERIAN ESTAR DISPONIBLES PARA EXTENDERSE PERO CERRADAS PARA MODIFICACION.

Este es uno de los más antiguos principios del Diseño Orientado a Objectos. Esto se puede resumir como "Cualquier entidad, debería permitir que su comportamiento pueda ser modificado (extendido), pero sin alterar su código fuente. Suena bastante fácil para cualquier desarrollador, pero es más complicado implementarlo a gran escala.

LSO: Liskov Substitution Principle

FUNCIONES QUE USEN... REFERENCIAS A CLASES BASE, DEBEN SER CAPACES DE USAR OBJETOS DE CLASES DERIVADAS SIN EXPLICITAMENTE CONOCER ESTOS OBJETOS.

Un resumen rápido: Si tenemos una clase base BASE, y subclases SUB1 y SUB2 el resto del código debería siempre referenciar a BASE y NO a SUB1 y SUB2.

ISP: Interface Segregation Principle

LOS CLIENTES NO DEBERÍAN SER FORZADOS A DEPENDER DE INTERFACES QUE ELLOS NO USAN.

Básicamente, si tenemos una clase abstracta o una interfaz, entonces, quienes implementen estas clases no deberían ser forzados a implementar partes que para un comportamiento específico no importan. Un caso de la vida real: Intenta crear un CustomMembershipProvider, heredando de MembershipProvider, son más de 20 métodos para sobrescribir, de las cuales a lo mejor solamente necesitas 5, he ahí una violación a ISP. El éxito llega con la creación de una serie de interfaces o clases abstractas que permita la modularización de objetos, sus propiedas y/o métodos.

DIP: Dependency Inversion Principle

A. MODULOS DE UN NIVEL ALTO NO DEBERÍAN DEPENDER DE MODULOS DE BAJO NIVEL. LA DEPENDENCIA ENTRE AMBOS DEBE SER REALIZADA SOBRE ABSTRACCIONES.

B. LAS ABSTRACIONES NO DEBERIAN DEPENDER DE DETALLES. LOS DETALLES PODRIAN DEPENDER DE ABSTRACCIONES.

Este último principio es la evolución natural de los tres primeros, la conclusión obvia. Una ayuda para el diseño "elegante" y a la vez manejar las responsabilidades y separación a nivel de assemblies o "módulos".

Microsoft ASP.NET MVC 1.0 es ahora Open Source MS-PL

Javier Romero — Thu, 02 Apr 2009 01:46:00 GMT

El código fuente de ASP.NET MVC ha estado disponible en CodePlex desde hace algún tiempo. Ojo con la palabra usada "Disponible", es decir había estado "abierto" para revisarlo, verlo, comentarlo pero no era "Open Source".

Puest ScottGu ha posteado sobre esto hace algunos momentos: Hoy ASP.NET MVC 1.0 además de ser "Gratis" ahora es "Libre" y ha sido liberado bajo la licencia MS-PL. Esto significa poderlo cambiar, redistribuir los cambios e incluso "dañarlo" (en el buen sentido de la palabra).

Muy buenas noticias para todos, especialmente para las personas del movimiento ALT.NET quienes buscan siempre mejoras a nivel comunidad para .net, además para nosotros que podremos buscarle los puntos más avanzados de MVC para el bien de todos.

Para más información sobre esta gran noticia algunos enlaces imperdibles:

Descarga ASP.NET MVC 1.0

En la página de descargas de Microsoft puedes descargar el release de Asp.net MVC. O puedes instalarlo a través del Microsoft Web Platform Installer V2. Si te das cuenta y revisas en la parte inferior de la página de descarga verás los enlaces tanto para el instalador (MSI), como para el código fuente, éste incluye un proyecto de Visual Studio 2008 para poder compilarlo.

Muy buenas noticias para todos...

Decisión: Usar Sharp Architecture para desarrollo en MVC

Javier Romero — Wed, 01 Apr 2009 21:32:00 GMT

Al comenzar a crear una aplicación web, sea esta en webforms o en mvc, una de las primeros requisitos a cumplir es la implementación de una arquitectura base que nos permita construir una aplicación web mantenible y escalable. Además, como expliqué en el post anterior el implementar mvc nos presenta otras consideraciones: IOC, Dependency Injection, y en este sentido entra en juego Sharp Architecture.

Qué es Sharp Architecture?

Me limito a citar lo expuesto por el equipo de sharp:

Architectural foundation for building maintainable web applications with ASP.NET MVC

Sharp nos brinda mediante una Plantilla de Proyecto de Visual Studio, la creación de una solución lista con mapeo de base datos utilizando Nhibernate, Inversion of Control (IoC) utilizando Castle Windsor, adiciones y helpers para MVC basadas en MVC Contrib que nos permiten desde ya tener un punto de partida para organizar y arquitecturar nuestra aplicación.

Qué ventajas tiene Sharp Architecture?

En primer lugar una guía de mejores prácticas para la implementación de Aplicaciones realmente mantenibles y escalables.
Mapeo de Base de Datos: la utilización de Nhibernate junto con Fluent-Nhibernate, un ORM Mapper realmente maduro, manejando de forma rápida y muchas veces automática (con AutoPersistance) la interacción con la base de datos.
NUnit como framework de pruebas: El proyecto de pruebas está basado en Nunit, con scripts listo para la compilación en un servidor de integración.
Generación automática de código basado en plantillas T4. Las cuales generan los modelos (clases), controladores, vistas de CRUD, mapeo de base datos y pruebas básicas para poder comenzar el desarrollo "en serio"

Cómo obtengo Sharp y comienzo a trabajar?

1. Descargar la plantilla o el código fuente: En Google Code puedes encontrar los últimos releases o hacer "checkout" del trunk para tener la última versión desde el repositorio Subversion.

2. Leer la Documentación de uso de la plantilla: Dentro del release existe documentación de 50 páginas de cómo comenzar, exponiendo conceptos básicos de TDD, DDD, Nhibernate y mvc, junto con directivas básicas para el desarrollo utilizando Sharp. Adicionalmente puedes empezar leyendo este excelente artículo en TheCodeProject que guía al uso de NHibernate.

3. Crea tu primera aplicación con Sharp Architecture.

El trabajo realizado por el equipo de Sharp es espectacular y en el grupo de Google puedes encontrar mucha información y soporte. Este foro tiene mucho movimiento, lo que indica la madurez y compromiso. Un buen trabajo sin dudar.

Mientras tanto preparo el material para desde nuestro siguiente encuentro comenzar "manos en la masa" con el desarrollo en Sharp.

Happy Coding & testing.

Asp.net MVC ya está en producción y ahora que?

Javier Romero — Tue, 31 Mar 2009 02:17:00 GMT

En el Mix 09, el equipo liderado por Scott Guthrie, realizó el lanzamiento de la versión final del framework de presentación asp.net mvc 1.0, un acontecimiento para algunos, una novedad para otros, algo nuevo para aprender para algunos y una gran oportunidad para otros. Éste último punto es el que me atañe y el punto sobre el cual se basa el concepto de este sitio.

Ir un paso más allá y encontrar dentro de todo este revuelo de asp.net mvc la utilidad “real” con “beneficios de negocios” palpables que nos permita el tiempo de “investigación” dentro de las organizaciones en la que laboramos. Y es que lo tenemos claros, el inmiscuirnos en algo nuevo es emocionante, cautivamente y hasta divertido… pero extremadamente demandante de tiempo necesario para otros proyectos.

Así Devlixir publicará una serie de artículos en base a la experiencia con la implementación de las versiones Beta, RC1 y RC2 de mvc, decisiones de arquitectura, comentarios sobre la validez y eficiencia del uso de mvc y en qué escenarios.

MVC, más allá de la Vista y el Controlador.

La adopción de mvc para desarrollo web, es más que simplemente cambiar la forma en la que realizamos la capa de presentación. Para mí y mi equipo es la oportunidad de implementar más estrategias de ingeniería al desarrollo web que nos permitan seguir brindando aplicaciones de calidad, escalables, seguras y accesibles de casi cualquier dispositivo. Brindando a la vez experiencias realmente ricas a los usuarios.

Conceptos como Test Driven Development (TDD), Domain Driven Design(DDD), Inversion of Control (IoC) aplicados a soluciones a nivel empresarial y de corporaciones, integrando sistemas, listas para crecer y con gestión de calidad desde la mínima unidad de código son como música para mis oídos expectantes de retos e innovaciones.

Lo que nos espera

Pues lo que espero podamos cumplir en este blog es la publicación de artículos de principio a fin de la implementación de mvc para un proyecto “real”, definiendo como real no el proyecto en sí, sino el contexto de ejecución de la aplicación, su impacto en el negocio del “cliente ficticio”, la implantación de este framework – metodología – patrón – etc. en un equipo multidisciplinario de desarrollo, buscando resultados y éxitos palpables.

Espera el resto de posts… empezaremos con conceptos y decisiones…

Nos vemos… happy coding (y testing)