dedicada a los profesionales de la plataforma .NET www.dotnetmania.com nº 57 marzo 2009 6,50 € Visual Basic • C# • ASP.NET • ADO.NET • AJAX • Silverlight • .NET Framework dotNetManía Consulta de modelos conceptuales con Entity SQL (II) • Interop en C# y C++/CLI. Dos puntos de vista de un mismo concepto La sencillez de una interfaz compleja SQL Server Performance Studio Creación de colectores de datos personalizados entrevista Brian Harry y Stephanie Saad Product Manager y General Program Manager de Team Foundation Server Microsoft Corp. SQL Server WCF y Silverlight juntos TodotNet@QA Las 12 preguntas de Spolsky y Team System ALManía
Transcript
dedicada a los profesionales de la plataforma .NET
Bienvenido al número 57, de marzo de2009, de dotNetManía.
Brian Harry es uno de los desarro-lladores “históricos” de Microsoft. Tra-bajó en el desarrollo del núcleo deVisual SourceSafe en 1992 (cuando,como él dice, no había ni navegadoresWeb), participó en el runtime del CLRy las librerías de .NET Framework, ydesde 2002 trabaja con el equipo deTeam System como Product Managerde Team Foundation Server. Es ademásel jefe de Stephanie Saad, nuestrasegunda entrevistada de este mes, quees General Program Manager paraTeam Foundation Server y que ha esta-do trabajando los últimos 5 años en elnúcleo de Visual Studio Team System.Ambos son entrevistados por MagdaTeruel y Luis Fraile, en su últimaentrega de tres entrevistas de “dos ados” que venimos publicando desde elmes de enero.
En la segunda entrega de su seriesobre Entity SQL, Unai Zorrilla yOctavio Hernández presentan lasprincipales características del lenguajey cómo probar las consultas mediantela herramienta eSqlBlast.
Con las tecnologías actuales, comoWPF, somos capaces de crear interfa-ces cada vez más complejas técnicamen-te, pero que además han de ser senci-llas tanto de usar como de mantener.Pero ¿de qué herramientas disponemospara realizar estas interfaces comple-
jas? En “La sencillez de una interfazcompleja”, Eduard Tomàs hace unaintroducción a PRISM, el marco de tra-bajo para el desarrollo de aplicacionesWPF propuesto por Microsoft Patterns& Practices para hacer posible la crea-ción de aplicaciones más manteniblesy extensibles.
¿Quién no ha tenido que usar desdesu lenguaje .NET preferido una DLLexterna programada en C o C++? Rafa-el Ontivero nos explica en “Interop enC# y C++/CLI. Dos puntos de vista deun mismo concepto” cómo interoperarentre código manejado y código nomanejado tanto desde C# como desdeC++/CLI.
Después de la introducción a las nue-vas posibilidades de monitorización deinstancias de SQL Server 2008 que Ela-dio Rincón hizo el mes pasado, en lacolumna de este mes mostramos cómocrear y capturar información de moni-torización mediante colectores de datospersonalizados en “SQL Server Perfor-mance Studio. Creación de colectoresde datos personalizados”.
Por último, en ALManía, con “Las12 preguntas de Spolsky y Team Sys-tem” damos una idea sobre cuál es elmejor punto de partida de un desplie-gue de Team System, valiéndonos dealgunos de los puntos propuestos porJoel Spolsky.
Pero esto no es todo, dentro haymás. Espero que sea de su agrado.
Editorial
editorialDedicada a los profesionales de la plataforma .NET
sumario 57Entrevista a Brian Harry y Stephanie Saad 10-13
Durante el Tech-Ed 2008, celebrado en Barcelona el pasado noviembre, dotNetManía tuvo laoportunidad de conversar con Brian Harry y Stephanie Saad, destacados miembros del equipo quedesarrolla Team Foundation Server en Microsoft.
Consulta de modelos conceptuales con Entity SQL (II) 14-18En nuestra entrega anterior, presentamos los conceptos fundamentales relacionados con Entity SQL,el lenguaje de consulta de modelos conceptuales incorporado al Marco de entidades de ADO.NET(ADO.NET Entity Framework), y mostramos el papel que este lenguaje juega dentro de esenovedoso marco de trabajo y las posibilidades que ofrece. A partir de este mes, nos centraremos endescribir su sintaxis y semántica, y en mostrar cómo hacer uso de éstas para resolver situacionessimilares a las que encontraremos frecuentemente al consultar nuestros modelos.
La sencillez de una interfaz compleja 20-30En este artículo se hace una introducción a PRISM, el marco de trabajo para el desarrollo deaplicaciones visuales WPF propuesto por Microsoft Patterns & Practices para hacer posible lacreación de aplicaciones más mantenibles y extensibles. También se presentan diversos patronesrelacionados con PRISM, como Presentación separada e Inversión de control.
Interop en C# y C++/CLI. Dos puntos de vista de un mismo concepto 33-42La interoperación entre código manejado y no manejado es una de las tareas que se presentanfrecuentemente a cualquier programador .NET. Aquí se describen detalladamente dos enfoquesdiferentes: el primero, haciendo uso de los recursos que ofrecen para ello C# y .NET; el segundo,utilizando C++/CLI, una extensión de C++ diseñada con la interoperabilidad como uno de susobjetivos centrales.
SQL Server Performance Studio. Creación de colectores de datos personalizados 44-47
En nuestra entrega anterior[1], hicimos una introducción a las nuevas capacidades de SQL Server2008 para monitorizar instancias de SQL Server; en el artículo de este mes, vamos a salirnos unpelín del "estándar" que ofrece la interfaz gráfica para adaptar el producto a nuestras necesidadesconcretas. Antes de seguir adelante, recomendaría familiarizarse con los conceptos tratados en elartículo del mes pasado.
Las 12 preguntas de Spolsky y Team System 48-52Una de las primeras preguntas que se hacen al empezar a implantar Team System es ¿y por dóndeempiezo? ¿qué hago? Son tantas las prácticas, herramientas, decisiones, que se hace difícil arrancar.Sin embargo, Joel Spolsky propuso hace tiempo 12 sencillas preguntas para evaluar nuestrasituación. Pues bien, vamos a darle una vuelta a esas preguntas, para usarlas como punto decomienzo.
dnm.todotnet.qa WCF y Silverlight juntos 54-56
Este mes exploramos aspectos internos de los enlaces (bindings) de WCF y cómo se relacionan conSilverlight. En particular, veremos las razones por las que en Silverlight no hay wsHttpBinding ysolo se soporta el esquema más simple de basicHttpBinding. También hablaremos sobre el modo decompatibilidad WCF/ASP.NET y la instalación de Silverlight en empresas de gran tamaño.
Lanzamiento de Office Communications Server 2007 Release 2
A principios de febrero, Mike Nash,vicepresidente de Windows ProductManagement en Microsoft, presentóWindows 7 and Windows Server2008 R2 Ecosystem Readiness Pro-gram, un programa diseñado espe-cialmente para ayudar a los fabri-cantes y vendedores de hardware ysoftware, así como a ISV y desarro-lladores en general, a alcanzar lacompatibilidad e innovación conWindows 7. Todos esos partners sonelementos claves para el éxito en lalabor de llevar nuevas posibilidades
al escritorio de los clientes. El pro-grama Readiness ofrece a los partnersacceso a las versiones beta de Win-dows 7 y Windows Server 2008 R2,kits de desarrollo y pruebas, docu-mentos técnicos y laboratorios parapruebas de aplicaciones a través deMicrosoft Connect. Los partners desoftware pueden unirse al programavisitando http://www.msdn.com/windows.
Según Nash, "Estamos centradosen la tarea de asegurar que los part-ners tengan una grata experiencia conWindows 7 y puedan transformar enoportunidades de negocio las nuevascaracterísticas que hemos creado parael producto. Por ejemplo, en la medi-da en que las cámaras digitales, telé-fonos inteligentes y otros dispositi-vos electrónicos se hacen más y máscomunes, se abre ante nosotros laposibilidad de ayudar a los clientes aobtener más de esos dispositivos.Device Stage es una característicade Windows 7 que permitirá a lospartners crear nuevas experienciaspara los clientes, a la vez que satisfa-cer mejor sus necesidades y encon-trar aplicaciones y servicios a travésde una interfaz visual. La caracterís-tica multi-touch incorporada a Win-
dows 7, por otra parte, ofrece tam-bién excelentes oportunidades paralos desarrolladores de software. Laplataforma habilitará el acceso a lainformación de multi-touch, y ofre-cerá diversas API para la rotación,movimiento y zoom de objetos. Losdesarrolladores podrán apoyarse enestas API para hacer posible una inte-racción más natural e intuitiva con elPC".
Por otra parte, Windows Server2008 R2 habilita nuevos escenariosy posibilidades, a la vez que ofreceuna excelente plataforma para lasaplicaciones directamente sobre elsistema operativo, gracias a .NETFramework y a las aplicaciones y ser-vicios Web que se ejecutan sobreInternet Information Services (IIS).Windows Server 2008 R2 ofrecemejoras significativas sobre WindowsServer 2008 en áreas claves para elincremento en las prestaciones de lasaplicaciones, tanto nuevas como yaexistentes, tales como LiveMigrationcon Hyper-V, Windows PowerShell2.0, el soporte para múltiples núcle-os y arquitecturas NUMA, y .NETy ASP.NET en Server Core.
Microsoft lanza Readiness Program paraWindows 7 y Windows Server 2008 R2
Mike Nash, vicepresidente de WindowsProduct Management
A principios de febrero, Microsoftanunció la disponibilidad de Offi-ce Communications Server 2007Release 2 (R2), que ofrece audio yvideoconferencia enriquecidos,nuevas herramientas para desarro-lladores, así como capacidades devoz mejoradas. La salida de estanueva versión sienta una nueva basepara potenciar el actual momentode crecimiento de Office Commu-
nications Server, que durante elúltimo año ha contribuido a cam-biar la faz de las comunicacionesempresariales integrando audio yvideoconferencia, la Web, la men-sajería instantánea y el correoelectrónico en una plataforma inte-grada de colaboración configuradaalrededor de la forma en que lagente trabaja. En la economíaactual, empresas de todo el mundo
eligen Office Communications Ser-ver para mejorar su productividad,reducir costes y ofrecer a susempleados las ventajas de las comu-nicaciones unificadas.
Para conocer todas las noveda-des que incorpora Office Commu-nications Server 2007 R2, consulteel documento http://www.micro-soft.com/presspass/presskits/uc/docs/OCS2007R2FS.doc.
El pasado día 3, Microsoft anunció susplanes en relación con las futuras edi-ciones de Windows 7, expresando quelas necesidades de mayor parte de losclientes estarán bien cubiertas a travésde las dos ediciones principales: • Windows 7 Home Premium, la
opción recomendada para los consu-midores finales, que obtendrán unaexperiencia de utilización total del PCy un entorno visual muy rico, queenglobará desde el entretenimientohasta la manera de conectarse a los dis-positivos.
• Windows 7 Professional, la opciónrecomendada para los pequeños nego-cios y para quienes trabajan desde casapero operan bajo entornos de empre-sa en los que la seguridad y la pro-ductividad son claves. Para quienes uti-lizan hoy en día Windows Vista Busi-ness, el cambio natural sería a Win-dows 7 Professional.
El primer cambio en la composiciónde las diferentes ediciones ha estado orien-tado a garantizar que todas las edicionesde Windows 7 serán subconjuntos unasde las otras. O sea, que al pasar de una edi-ción a la superior, los usuarios seguirándisponiendo de todas las características dela anterior. Esto no ocurrió con WindowsVista, donde por ejemplo al pasar de la
edición Home Premium a la Business sepierde la funcionalidad relacionada conMedia Center.
El segundo cambio consiste en queWindows 7 ha sido diseñado de modo quelas diferentes ediciones del sistema pue-dan ejecutarse sobre una gama muy ampliade hardware, que va desde los pequeñosnetbooks hasta los escritorios más poten-tes. De esta manera, los clientes podránhabilitar los escenarios deseados a lo lar-go de todas las posibilidades de hardwarea su alcance.
Por último, el tercer cambio radica enla manera de comunicar estas ediciones almercado, de manera que las diferentesopciones queden lo más claro y simpleposible a clientes y partners.
No obstante a creer que las dos edi-ciones antes mencionadas satisfarán lasnecesidades de la mayoría de los clien-tes, Microsoft comprende que numero-sos usuarios (de entre los más de 1.000millones actualmente estimados) pue-den tener necesidades especiales, por locual ha concebido otras cuatro edicio-nes de Windows 7 situadas en los“polos” del espectro:• Solo para los mercados emergentes,
seguirá existiendo una edición HomeBasic, que permitirá disfrutar de unaexperiencia básica de uso de Windowsincluso en sistemas muy modestos.
• También continuará existiendo, aho-ra a nivel mundial, la edición Win-dows Starter, que solo se ofrecerá preinstalada por los OEM y limitada atipos específicos de hardware.
• En la parte superior del espectro, paralos clientes corporativos más grandesse continuará ofreciendo la ediciónEnterprise, que ofrecerá protecciónde datos avanzada y herramientas parafacilitar la gestión del PC y ayudar aahorrar costes, permitiendo al mismotiempo el acceso universal a la infor-mación a los usuarios de negocio.
• Por último, para quienes quieren dis-poner de todo lo que Windows 7tendrá para ofrecer, seguirá existien-do la edición Ultimate.
Los precios de venta de cada una deestas ediciones no han sido anunciadoshasta el momento.
Anunciadas futuras ediciones de Windows 7
A principios de febrero, el equipo deEvangelismo de Azure Services puso adisposición del público una actualiza-ción de Azure Services Training Kit.Este kit de entrenamiento se preparóoriginalmente para los hands-on labs dela PDC'08, y es una herramienta de granutilidad para familiarizarse con la pla-taforma de servicios de Azure.
La nueva actualización agrega a losya disponibles anteriormente lossiguientes contenidos sobre WindowsAzure, .NET Services, SQL Services yLive Services:
Hace solo unos días, se ha puesto a dis-posición de los desarrolladores el SDKde Microsoft Semblio, una herramien-ta orientada al mercado educativo y quepermitirá crear experiencias de apren-dizaje ricas, con un alto nivel de inte-ractividad y que promuevan la explora-ción y la colaboración. Semblio ofreceun enfoque de nivel de plataforma a lacreación de contenidos, y se apoya enlas facilidades de .NET Framework yen concreto de WPF para satisfacer lacreciente demanda de soluciones apren-dizaje más personalizables, permitien-do a la vez un alto nivel de control sobrela adaptación de los materiales.
Semblio no es solamente unaherramienta para desarrolladores;Microsoft ha confirmado que la pró-xima edición de Office incluirá unaherramienta de composición (con lainterfaz de usuario familiar de las apli-caciones de Office) que permitirácombinar múltiples tipos de conteni-dos en una única presentación multi-media, así como un reproductor quelos educadores y estudiantes podránutilizar para ver e interactuar con laspresentaciones.
Para más información y descar-gas, visite http://www.microsoft.com/learningspace/semblio.
Microsoft Semblio SDK
El próximo 3 de marzo se celebrará elevento online de actualización tecnoló-gica Windows Day. Tecnología paraderribar paredes, organizado porMicrosoft Ibérica y Microsoft Latino-américa, y dirigido a desarrolladores yprofesionales de TI.
Durante este evento se podrá asis-tir a charlas con demostraciones técni-cas que abordarán temas como la imple-mentación de Windows Vista, la vir-tualización del desktop, las novedades enWindows 7, nuevas características deseguridad o las interfaces de usuario uti-lizando tecnologías como Silverlight y.NET. Además, se compartirá un aná-lisis de los desafíos que surgen de lavisión Software + Servicios propuestapor la compañía, entre muchos otros.
Los asistentes tendrán la ocasión departicipar en encuentros vía chat con losoradores y otros especialistas, e inclusoadelantar sus consultas a través del blogdel evento en: WindowsDayBlog.net.
Las conferencias para desarrollado-res serán:• Dando el salto hacia el presente con
Windows Presentation Foundation.• El futuro de la plataforma de desa-
rrollo Web hoy.• Programando para videoclubs con
Silverlight 2.• Con .NET es más fácil: aplicaciones
efectivas con Windows Forms.• Mapa de ruta en el acceso a datos con
el .NET Framework 3.5.• Sí, ¡se puede trabajar con diseñadores!
Más información e inscripciones en:http://www.microsoft.com/latam/windowsday.
Tecnología sin barreras
Windows DayEl pasado 11 de febrero, Miguel deIcaza, vicepresidente de Novellpara la plataforma de desarrollo yfundador de Mono, anunció la dis-ponibilidad de Moonlight 1.0, unaimplementación open source de Sil-verlight 1.0 para Linux y otros sis-temas operativos de la familiaUnix/X11, que hace posible la eje-cución de aplicaciones Silverlighten esos sistemas, además de ofrecer
un SDK para el desarrollo de apli-caciones Silverlight.
Moonlight 1.0 se ofrece en formade plugin para FireFox 2.0 ó 3.0, y hasido probado en diferentes distribucio-nes de Linux (incluyendo SUSE Enter-prise Desktop y openSUSE) corriendosobre procesadores tanto x86 como x64.
Para obtener más información odescargar Moonlight, visite http://go-mono.com/moonlight.
Moonlight 1.0
A finales de enero, días después de lasalida a imprenta de nuestro ejem-plar anterior, Microsoft puso a dis-posición del público la CTP de ene-ro de 2009 del SDK de Oslo. Oslo esel nombre en clave de la plataformade desarrollo de próxima generaciónde Microsoft, cuyo objetivo es garan-tizar la multiplicación por 10 de laproductividad a lo largo del ciclo devida de las aplicaciones (diseño, desa-rrollo y gestión). Para cumplir esteobjetivo, Oslo se apoya en modelos,
lenguajes y herramientas para domi-nios específicos. Esta nueva CTP delSDK contiene documentación,ejemplos, copias de modelos de Osloescritos en el nuevo lenguaje M yherramientas que ayudan a la crea-ción de modelos por parte del desa-rrollador, incluyendo la que actual-mente se conoce como Intellipad.La CTP puede descargarse desdehttp://www.microsoft.com/downloads/details.aspx?FamilyID=f2f4544c-626c-44a3-8866-b2a9fe078956.
Durante el Tech-Ed 2008, celebrado en Barcelona el pasado noviembre, dotNetManíatuvo la oportunidad de conversar con Brian Harry y Stephanie Saad, destacados miem-bros del equipo que desarrolla Team Foundation Server en Microsoft.
Antes que nada, habladnos un poco de sobrevosotros, vuestro trabajo en Microsoft y a quédedicáis vuestro día a día.
Brian Harry: Mi nombre es Brian Harry ysoy Product Manager de Team Foundation Ser-ver (TFS). He trabajado en Microsoft como desa-rrollador desde 1992, año en el que comencé atrabajar en el núcleo de Visual SourceSafe. Lomás importante en lo que he trabajado, sin dudas,
han sido el runtime del CLR y las librerías de.NET Framework, pero en 2002 me cambié alequipo de Team System y al proyecto de TFS.
Stephanie Saad: Yo soy Stephanie Saad, y éles mi jefe (se ríe, señalando a Brian). Soy GeneralProgram Manager para TFS, y trabajo en Micro-soft desde hace 7 años. Antes de eso, estuve enuna Internet startup, de la que vine a Microsoftporque nuestro equipo de desarrollo estaba muy
Magda Terueles Team Leader de
Raona. Magda esMCPD Windows
Developer.http://www.magda.es.
Luis Fraile es MVP deTeam System y cola-bora activamente enMAD.NUG (Grupode usuarios de .NETde Madrid). Actual-mente es director
desorganizado, y pensé “Debe haberuna forma mejor que la nuestra dehacer todo esto”.
¿Y la había? Stephanie: Sí, la había, pero no tan
organizada como yo pensaba. Ha sidomuy divertido, sí. He trabajado conVisual Studio y sus herramientas casitodo el tiempo, empezando comoOperations Manager, y en los últimos5 años trabajando en el núcleo deVisual Studio Team System. Ahora tra-bajo en el proyecto de TFS.
Vosotros empezasteis con Source-Safe, y habéis trabajado con las ver-siones anteriores de Visual Studio.¿Cómo veis la evolución de estasherramientas hasta lo que tenemoshoy en día?
Stephanie: Pienso que esas prime-ras versiones eran buenas herramien-tas para los desarrolladores, realmen-te. Pero lo que tenemos hoy en día,con la repercusión de Team System yel enfoque hacia la gestión del ciclo devida de aplicaciones (ApplicationLifecycle Management, ALM) es espe-cial, porque se trata de un conjunto deherramientas para equipos enteros dedesarrolladores.
¿Y son las mejores herramientas? Stephanie: Probablemente podrías
encontrar mejores herramientas indi-viduales para cada una de las funcio-nalidades; pero lo que es realmentemuy costoso es conectar todas esasherramientas.
¿Incluso en el caso de herramientasOpen Source?
Stephanie: Es muy costoso, en dine-ro y tiempo. Lo que se ve de la evolu-ción de nuestra suite es que hemos idoconstruyendo buenas herramientas paradirectores de proyectos. Y ahora con lasnuevas versiones incorporamos herra-mientas para testers y grandes mejorasen las herramientas para arquitectos.Vais a ver que continuamos extendien-do esa línea a lo largo del tiempo: empe-
zamos con la primera versión, luegoprogresamos con la 2008 y de pleno conla versión 2010, y continuaremosampliando en futuras versiones.
Ha habido bastantes cambios desdeSourceSafe.
Brian: Sí, es que la gente se diocuenta de las cosas que le faltaban aSourceSafe tan pronto empezó a cam-biar el contexto. SourceSafe se diseñóen 1992, y si miras a esa época, noexistía Internet como lo conocemos hoyen día: ¡no había navegadores Web!
¡Parece imposible de creer! Brian: Sí, pero es cierto. Las redes
locales eran algo relativamente difícilde encontrar. La pregunta “¿Tienes unared?” era muy significativa. SourceSa-fe se creó en esa época, y el desarrollode software en ese periodo no era nimucho menos tan sofisticado como loconocemos ahora. Casi siempre erangrupos pequeños, compuestos prácti-camente solo por desarrolladores, el tes-teo era muy informal, no existía el con-cepto de prueba unitaria, y los reque-rimientos eran documentos muy arcai-cos y estáticos. Era un mundo comple-tamente diferente, y por ello se hizonecesario desarrollar TFS, cuando nosdimos cuenta de que el proceso de cre-ación de software se había convertidoen algo mucho más sofisticado.
Y hacía falta algo para cubrir esecambio.
Brian: Exactamente, necesitábamosun conjunto de herramientas quecubriesen el amplio abanico de activi-dades del proceso de desarrollo de soft-ware. Mientras que SourceSafe y losrepositorios de código son una buenae importante herramienta para equi-pos pequeños, no son suficientes paracubrir todas las necesidades de loscomplejos procesos de desarrollo desoftware de hoy en día.
Contadnos algo de la recién publi-cada versión de las Power Tools. ¡Esfantástica!
Brian: Personalmente, estoy muycontento con las Power Tools, porquenos dan la oportunidad de entregarvalor a los clientes con relativa fre-cuencia. Microsoft es una gran empre-sa, y hacemos grandes entregas, peropuede pasar mucho tiempo entre ellas.Eso hacen dos o tres años en los queentre medio no ofreces nada nuevo.Las Power Tools nos permiten entre-gar a los usuarios algo que les hace lavida más fácil cada tres meses. Conestas entregas no pretendemos cam-biar el modo de desarrollar, solo dina-mizarlo añadiendo pequeñas cosas quenos hacen ser más eficientes. La últi-ma versión publicada, en octubre, esprobablemente la mayor entrega quehemos hecho, hay cosas muy buenasincorporadas.
¿Algo que destacarías en ellas? Brian: Por ejemplo, las extensio-
nes para Windows Explorer. Ahorapuedes controlar versiones desde elExplorador de Windows. Puedes pro-teger código, desproteger, obtener laúltima versión, comparar los fiche-ros locales con lo que hay en el ser-vidor. Se puede hacer todo lo básico,y era una de las peticiones más popu-lares que hemos tenido en muchotiempo. Otra cosa que me gusta es lafuncionalidad de “Team Members”,ya que es dar un paso más para incor-porar a la gente a la experiencia delequipo.
¿Conectando a la gente? Brian: Siempre hemos intentado
conectar, pero ahora estamos real-mente conectándolos en cuanto a lastareas, los ficheros, los elementos detrabajo, los informes, los datos que haypor detrás, llevando toda esa informa-ción a todo el mundo. Dando visibili-dad, en definitiva. Hemos incorpora-do muchas funcionalidades, como lasconsultas sobre work items, y poderhacer preguntas como “Enséñame quécambios ha realizado esta persona enla última semana” y obtener una res-puesta rápidamente.
Habéis dicho que solo hay versiones cada dosaños, pero una de las cosas que más protestanlos usuarios es que continuamente salen nuevasversiones de VSTS, de .NET Framework, etc. yhay que adaptarse a los cambios. Para la versión2010 hay un montón de cosas nuevas, ¿lo tenéisen cuenta?
Stephanie: Eso es interesante, ya que recibimosfeedback en los dos sentidos. Algunos usuarios se que-jan, pero otros ven que aportamos valor en cada ver-sión y lo agradecen. Es importante focalizarse enactualizaciones. La pregunta no es tanto si tenemosque aportar valor regularmente, como si podemosayudar a los usuarios a incorporar ese valor a su díaa día, a entenderlo y utilizarlo.
Brian: Es cierto, coexisten las dos versiones, tan-to la de que en Microsoft se hacen las cosas lentas,como la de que publicamos versiones demasiado amenudo.
¿Cómo interpretas eso? Brian: Hay dos tipos de cambios. Por ejemplo,
la evolución de Windows Forms a Windows Pre-sentation Foundation es un gran cambio, y si hicié-ramos cambios como ése cada 6 meses o cada año lagente nos ajusticiaría. Los grandes cambios, esos quecambian la forma en que haces las cosas y cómo cons-truyes las aplicaciones, tienen que suceder no tanfrecuentemente, ya que son costosos de adoptar. Por
otra parte, recibimos muchas peticiones de usuariossolicitando pequeñas adiciones o cambios de fun-cionalidad. Son cosas que realmente no cambian laforma en que desarrollamos, pero que hacen nues-tra vida mejor y son fáciles de adoptar. Hacer regu-larmente entregas de este tipo es indudablementepositivo.La nueva versión de VS2010 ya está aquí, ¿qué eslo que os parece mejor? No vale decir “Todo elproducto”…
Stephanie: Me resultaría difícil escoger una o doscaracterísticas (risas). Tenéis que entender que Briany yo estamos realmente entusiasmados, porque nues-tra implicación es desde el principio. El primer mee-ting sobre la versión 2010 fue hace ya dos años ymedio; esta entrega es realmente buena.
¿Qué hay de las mejoras en Project Management? Stephanie: Lo principal ha sido para ayudar al
equipo de negocio a construir lo que necesitan. Aho-ra pueden trazar absolutamente todo, crear infor-mes, integrarse con Excel, hacer seguimiento conProject. Por fin las empresas pueden planificar deuna forma efectiva sus soluciones, se les da todo loque necesitan en forma de drag & drop entre herra-mientas.
¿Y en cuanto al testing? Stephanie: Es otro de nuestros grandes pilares.
Tenemos un fantástico entorno para desarrollado-res, y ahora una variante especialmente pensada paratesters. Por destacar algo, la ejecución de tests inte-grada en el entorno de desarrollo es genial. Puedesejecutar, capturar información y enviarla: encuen-tras un bug e inmediatamente lo reportas. Está biendiseñado, pensado para ser simple y atractivo, y hasupuesto una innovación desde el núcleo. Teníamosel compromiso de hacer la herramienta mejor, y enesta versión están las cosas que los usuarios real-mente necesitan.
Brian: Sí, a mí también me gustan mucho lasmejoras en testing. A los desarrolladores les va aencantar todo lo relacionado con la depuración depruebas. Van a ser mucho más productivos, hasta elpunto de que no van a saber cómo han podido vivirsin ello.
¿Y otros perfiles en los que hayáis pensado? Stephanie: También hemos pensado en los equi-
pos de TI, y en los arquitectos. Ahora podemosmover proyectos fácilmente, y esa es una cosa quelos usuarios llevan pidiendo mucho tiempo. Hemos
A los desarrolladores les va a encantar todo lo relacionado con ladepuración de pruebas, que les hará
hecho una gran inversión en esto, y me gusta muchocómo ha quedado.
Brian: Estoy de acuerdo con todo lo que ha dichoStephanie. Respecto a las mejoras en relación con laarquitectura, hay cosas magníficas: la capa de dia-gramas, la gestión de constraints o de las políticas decheck-in. Por último, mencionaría branch visualiza-tion, una novedad que permitirá a los equipos enten-der cómo progresa el desarrollo, cómo y cuándo cam-bian las cosas, ese tipo de cosas.
¿Cómo está adoptando Microsoft internamenteVSTS? ¿Es difícil para vosotros poner todos losgrupos de trabajo dentro de TFS?
Stephanie: Es un proceso lento para noso-tros. Lo estamos adoptando incrementalmente;empezamos con nuestro equipo, y luego el equi-po de Visual Studio. Después lo ha adoptado elgrupo de TI, y en otros grupos pequeños alre-dedor de la compañía la adopción está empe-zando a crecer lentamente.
¿Qué reacción habéis visto en los usuarios? Stephanie: ¡A la gente le gusta! Tenemos casi la
mitad de la compañía usándolo. Algo que hemosaprendido es que hay que empezar identificando elproblema que tiene el equipo, porque si el equipo estácontento con el control de código, o con el sistemade seguimiento de bugs, no tendrás mucho éxitohaciéndoles adoptar una nueva herramienta; tienesque averiguar cuáles son sus problemas. Para algunoses el servidor de control de código, para otros la ges-tión de proyectos, para otros la visibilidad sobre loque está pasando.
¿Se hace una implantación total? Stephanie: ¡No, no! Una vez identificado el pro-
blema, ahí empieza la historia. Tenemos un montónde grupos que solo usan una parte de TFS. Porejemplo, el grupo de Office solo usa la parte de ges-tión de proyectos; el de SQL solo usa la parte dework items; el de desarrollo lo utiliza todo exceptoel sistema de builds automáticos (lo migraremos másadelante).
¿Entonces cuál es el truco? Stephanie: Si identificas lo que preocupa tendrás
más oportunidades de mejorar el proceso. Para adop-tar TFS, tienes que empezar pensando en cuál es tupropio proceso de desarrollo y qué problemas te pue-de ayudar a resolver esa herramienta. Solo partiendode esa base te puede ayudar a ser más eficiente.
¿Y habéis publicado vuestra experiencia? Stephanie: Sí, Microsoft ha dado un gran paso al
publicar la plantilla de la guía de proceso de Micro-soft, basada en nuestra experiencia propia, nuestrasbest practices y en cómo hacemos las cosas. Estará dis-ponible próximamente.
Tal y como os ha pasado a vosotros, en las empre-sas no se está adoptando todo Team System.¿Qué opináis de ALM, estamos avanzando rápi-damente? ¿Se integra realmente con VSTS, oestamos solo usando el servidor de control decódigo fuente?
Stephanie: Lo que yo estoy viendo en nuestrosclientes es una adopción incremental, “pieza a pie-za”. Por ejemplo, en el Banco de Montreal hanempezado adoptándolo en un equipo pequeño, uti-lizando TFS como servidor de control de código,algo que era algo muy localizado dentro de la com-pañía. Pero el cliente se da cuenta rápidamente deotros beneficios que obtendrá al extenderlo a otrasáreas de la compañía. En equipos grandes, llevatiempo darse cuenta de toda la potencia que TFSpuede ofrecer. La forma inteligente es hacerlo pasoa paso, como hemos comprobado interna y exter-namente.
Brian: Cada tres meses tenemos una reunión detodo el equipo, y llevamos a un cliente cada vez, parahablar de su adopción del producto y qué significaesa adopción para él. Es muy interesante oír la his-toria específica de cada cliente, cómo TFS ha cam-biado su empresa y de qué manera concreta. Y sonempresas que decidieron usar no solo el servidor decontrol de código, si no que se han parado a pensaren cómo es su proceso, cómo coordinarse, manejarlos proyectos, las entregas, etc. Es una tecnología detransformación. He visto a mucha gente empezardando pasos pequeñitos, y luego convencerse de lautilidad de adoptar otras partes del producto.
¿Algún adelanto para las próximas versiones? Brian: Con miras a las próximas versiones, esta-
mos haciendo encuestas a los usuarios para saber quées lo que quieren. La idea general es focalizarse enla parte de trabajo en equipo, con un poco para cadarol involucrado en el proyecto. Pero hay mucha gen-te nueva involucrada en ALM, como los analistas denegocio, los gestores de TI, los controladores decalidad, etc. Más gente, más procesos, en continuaexpansión, y nosotros por nuestra parte tambiénvamos a continuar expandiendo el alcance de nues-tras releases a nuevas áreas.
Describiremos las posibilidades que ofrece EntitySQL utilizando un enfoque práctico y basado enejemplos. Una referencia completa del lenguaje seofrece en el Apéndice B de nuestro libro [2], asícomo en MSDN [5]. Como ya es habitual, utiliza-remos para los ejemplos un modelo conceptual cre-ado a partir de la base de datos FUTBOL2006, apare-cida inicialmente en [3] y que luego hemos venidoutilizando en nuestra anterior serie sobre los fun-damentos del Marco de entidades [4] y en el artí-culo anterior de ésta [1]. Como "cajón de arena"para la realización de pruebas, le recomendamosque utilice la herramienta eSqlBlast, cuyos princi-pios básicos de funcionamiento se describen en elrecuadro que aparece en la página 16. Un buen ejer-cicio para familiarizarse con Entity SQL consisteen intentar "adivinar" de antemano qué hace unaconsulta dada y qué estructura tendrá su conjuntode resultados. Para ayudarlo en ese objetivo, a lolargo de esta serie no describiremos verbalmentequé resultados producen las consultas. Otro buenejercicio, ya algo más avanzado, puede ser el análi-sis de las consultas nativas (de T-SQL, siempre queutilicemos un modelo basado en SQL Server) enlas que el Marco de entidades transforma las con-sultas Entity SQL, para intentar comprender los
principios generales que guían ese proceso. En cual-quier caso, puede jugar con la herramienta con latotal seguridad de que no estropeará nada, dado queel lenguaje (al menos en su versión actual) sola-mente ofrece posibilidades para la consulta demodelos.
GeneralidadesEntity SQL (también conocido como eSQL, abre-viatura que utilizaremos en lo adelante) ha sidodiseñado especialmente como vehículo para darsoporte a las consultas sobre modelos de datos deentidades, y permite explotar toda la potencia deexpresión que incorporan dichos modelos, inclu-yendo por supuesto características como la heren-cia, las relaciones o los tipos complejos. Entre losrequisitos fundamentales sobre los que se apoyó eldiseño del lenguaje, podemos mencionar lossiguientes:
• Estar basado en SQL, el estándar indiscu-tible en lo que a gestión de datos se refiere,para facilitar su rápida adopción por los desa-rrolladores. No obstante, incluso en la sinta-
Consulta de modelos conceptualescon Entity SQL (II)
En nuestra entrega anterior [1], presentamos los conceptos fundamen-tales relacionados con Entity SQL, el lenguaje de consulta de modelosconceptuales incorporado al Marco de entidades de ADO.NET (ADO.NETEntity Framework), y mostramos el papel que este lenguaje juega dentrode ese novedoso marco de trabajo y las posibilidades que ofrece. A par-tir de este mes, nos centraremos en describir su sintaxis y semántica, yen mostrar cómo hacer uso de éstas para resolver situaciones similaresa las que encontraremos frecuentemente al consultar nuestros modelos.
Unai Zorrilla, Octavio Hernández
Unai Zorrilla esDevelopment Team
Leader de Plain Concepts.MVP desde 2004,
colabora activamente conMicrosoft en eventos de
arquitectura y desarrollo, así como en
giras de productos. Autorde los libros “Modelandoprocesos de negocio conWorkflow Foundation” y
“ADO.NET EntityFramework: Aplicaciones y
servicios centrados endatos”.
Octavio Hernández esMVP de C# desde 2004,MCSD y MCT. Autor de
xis existen algunas diferencias necesarias entreSQL y eSQL, que iremos mencionando a lo lar-go de éste y los siguientes artículos.
• Soportar todos los tipos de datos y cons-trucciones de EDM, obviamente.
• Independencia de cualquier dialecto de SQLo proveedor de ADO.NET concreto, para quelas consultas y las aplicaciones que las utilicensean virtualmente independientes del proveedorde ADO.NET y la base de datos subyacentes.Este es un aspecto de gran importancia a la horade desarrollar y mantener aplicaciones capacesde trabajar contra diferentes motores de basesde datos relacionales.
• Ortogonalidad y soporte para la composición.A diferencia de la mayoría de las implementacio-nes de SQL, en eSQL las expresiones se tratan deuna manera ortogonal, de manera que se puedecolocar virtualmente cualquier expresión en cual-quier posición de una expresión SELECT. Por ejem-plo, en T-SQL una subconsulta en la cláusulaSELECT debe evaluarse a un valor escalar, y en lacláusula FROM a una colección; estas inconsisten-cias no existen en eSQL. Como ejemplo, consi-dere la sentencia del listado 1, que incluye unasubconsulta no escalar en la cláusula SELECT. En latabla 1 se puede ver un fragmento del conjuntode resultados que esta consulta produce; recuer-de de nuestro artículo anterior que los conjuntosde resultados que produce la ejecución de una sen-tencia eSQL pueden ser mucho más complejosque los que devuelve un proveedor tradicional deADO.NET que ejecute una sentencia SQL.
• Soporte para las colecciones como ciudadanos deprimera clase. Los conjuntos de entidades con quetrabaja el Marco son tratados como colecciones deobjetos de los tipos correspondientes. Del mismomodo, eSQL ofrece mecanismos para construir colec-ciones ad hoc de elementos de diversa naturaleza, ylas colecciones se pueden crear, anidar y proyectarcomo cualquier otro tipo soportado por EDM. Por
ejemplo, en la consulta del listado 2 se construye y uti-liza como filtro una colección de cadenas de caracte-res. Como se puede observar, la sintaxis para construircolecciones se usan llaves, al estilo de C#1. Del mismomodo, la consulta del listado 3 utiliza una colección,en este caso de entidades del tipo Pais del modelo.
Tabla 1. Fragmento del resultado de la consulta del listado 1.
SELECT P.Nombre, (SELECT F.Nombre, F.Club FROM FUTBOL2006Entities.Futbolista A S F WHERE F.Pais.Codigo = P.CodigoORDER BY F.Nombre) A S Futbolistas
FROM FUTBOL2006Entities.Pais A S P
ORDER BY P.Nombre
Listado 1. Consulta eSQL con subconsulta en cláusula SELECT
SELECT F.Club.Nombre, COUNT(F.Id) FROM FUTBOL2006Entities.Futbolista A S F WHERE F.Posicion IN { ‘P’, ‘D’ }GROUP BY F.Club.Nombre
HA VING F.Club.Nombre LIKE ‘%MA D%’
SELECT P.NombreFROM (FUTBOL2006Entities.Pais UNION
{ FUTBOL2006Model.Pais(‘CU’, ‘CUBA ’), FUTBOL2006Model.Pais(‘US’, ‘ESTA DOS UNIDOS’) })
A S P
ORDER BY P.NOMBRE
Listado 2. Consulta eSQL con colección creada ad hoc.
Listado 3. Otra consulta eSQL con colección creada ad hoc.
1 eSQL también ofrece el operador MULTISET (por ejemplo, MULTISET('P', 'D')) con el mismo objetivo.
eSqlBlast es una utilidad que permite ejecutar directamenteconsultas eSQL contra modelos de entidades, creada a fina-les de 2007 por Zlatko Michailov, entonces miembro delequipo de desarrollo de Entity Framework. Microsoft ofreceel código fuente (escrito en C#) de esta herramienta, que pue-de descargarse desde http://code.msdn.microsoft.com/esqlpara luego compilarlo con cualquier versión de Visual Studio2008, incluyendo, en principio, Visual C# Express. Decimos"en principio" porque el código está estructurado en formade un núcleo (librería de clases comunes) sobre el que luegose apoyan diferentes proyectos que proporcionan interfacesde usuario de consola, Windows y Web. Si está usando VisualC# Express, no podrá abrir ni compilar el proyecto de inter-faz Web, que podrá eliminar de la solución. Aquí describire-mos la versión con interfaz de usuario Windows; el nombredel ejecutable que se obtiene es Microsoft.Samples.Data.eSql-Blast.WinShell.exe.
Si se ejecuta el proyecto una vez compilado, se obtie-ne la interfaz de usuario que se muestra en la figura 1. Bási-camente, eSqlBlast ofrece cinco pestañas:
• Connection, en la cual debemos introducir la infor-mación que eSqlBlast necesita para poder ejecutar lasconsultas eSQL contra un modelo.
• Model, en la que podemos obtener un conjunto depáginas con hiperenlaces que muestran, de una mane-ra clara e intuitiva, información del modelo.
• Query, en la que podemos introducir una sentenciaeSQL que queramos ejecutar. El editor que se ofre-ce aquí brinda ciertas facilidades rudimentarias, comoel coloreado basado en la sintaxis. Al pulsar el botónde ejecución, automáticamente se salta a la siguientepestaña.
• Results, en la que se muestran de forma tabular losresultados de la ejecución de las consultas, o los men-sajes de error que se puedan producir durante la eje-cución. Una información adicional relevante que semuestra es el comando del almacén (store command),o sea, la traducción de la sentencia eSQL al dialectode SQL del motor de bases de datos subyacente (ennuestro caso, T-SQL).
• About, que muestra los créditos de la aplicación.
Como puede verse en la figura 1, para poder ejecutarconsultas con eSqlBlast es necesario suministrar:
• El nombre del proveedor ADO.NET con el que se acce-de a la base de datos subyacente; en nuestro caso, Sys-tem.Data.SqlClient, dado que utilizamos SQL Server.
• La cadena de conexión del proveedor utilizada paraconectarse a la base de datos subyacente. Puede obte-
nerse fácilmente, pues forma parte de la cadenade conexión del modelo (el valor de la propiedadConnection String del modelo, ver figura 2).• La ruta física a los ficheros SSDL, MSL y
CSDL que componen el modelo. En este últi-mo caso, recuerde que, por defecto, cuandose crea un modelo de entidades en un pro-yecto de Visual Studio 2008, esos ficheros seembeben como recursos dentro del ejecuta-ble. Se puede obtener estos ficheros de mane-ra independiente cambiando el valor de la pro-piedad Metadata Artifact Processing (Tra-tamiento de artefactos de metadatos) delmodelo de su valor predeterminado (Embedin Output Assembly, Embeber en ensam-blado resultante) al valor Copy to OutputDirectory (Copiar a directorio de salida),como se muestra en la figura 2, y regeneran-do el proyecto.
La herramienta eSqlBlast
Figura 1. Interfaz Windows de eSqlBlast
Figura 2. Generando los ficheros del modelo para eSqlBlast.
Como ya hemos mencionado anteriormente, eSQL esun lenguaje para definir consultas sobre modelos deentidades, y en él prácticamente todo es una expresión.Las consultas se pueden definir de dos maneras:
• Utilizando directamente una expresión válidadel lenguaje. Por ejemplo, en el listado 4 se mues-tran varias maneras equivalentes de definir unamisma consulta, la primera utilizando una sim-ple expresión.
• Utilizando una expresión de consulta SELECT.Observe en el listado 4 que el alias para la expre-sión de la cláusula FROM es opcional (aunque su usoes siempre recomendado). A la cláusula VA LUE lededicaremos un epígrafe especial más adelante.
Expresiones “básicas”
En la construcción de expresiones, los nombres de enti-dades, propiedades, etc. del modelo se pueden combi-nar con otros recursos típicos de cualquier lenguaje [2]:
• Literales, para representar valores constantes delos tipos soportados por EDM.
• Variables y parámetros, que utilizan conveniossintácticos similares a los de T-SQL. En parti-cular, los nombres de parámetros deben comen-zar con el carácter @.
• Operadores. Además de los más tradicionales(aritméticos, lógicos, relacionales), se ofrece todoun conjunto de operadores especiales relaciona-dos con la herencia, navegación de relaciones yotros, algunos de los cuales iremos presentandoen próximas entregas.
• Funciones. Aquí Microsoft ha definido un con-junto de funciones canónicas que deberán serimplementadas por todos los proveedores parael Marco de entidades. Por otra parte, los fabri-cantes de cada proveedor concreto para el Mar-co de entidades son libres de suministrar sus pro-pias "funciones extendidas", que serán válidas solo
para ese proveedor. Como ejemplo, considere laconsulta que se muestra en el listado 5. En ellase utiliza una función canónica, CURRENTDA TETIME,y otra específica del proveedor de SQL Server,SqlServer.DA TEDIFF.
Expresiones de consulta SELECTLas expresiones de consulta SELECT de eSQL (no con-fundir con las expresiones de consulta de C# o VB) siguenla sintaxis SFWGHO (SELECT-FROM-WHERE-GROUPBY-HA VING-ORDERBY) tradicional de SQL, con ligeras dife-rencias. Puede encontrar un listado completo de estasdiferencias en MSDN [5]. Además de las que ya hemosmencionado al principio de este artículo (ortogonalidaden uso de expresiones, soporte para colecciones), desta-caremos ahora las siguientes:
• Lo primero a destacar es el hecho de que eSQLno soporta SELECT *; se requiere indicar explíci-tamente las expresiones a recuperar.
• En segundo lugar, todas las referencias a pro-piedades de las entidades del modelo deben sercualificadas con el nombre de la entidad o unalias de ésta, como puede observarse en los lis-tados 1, 2 y 3.
• Por último, en eSQL aparece la cláusula VA LUE,a la que dedicaremos la siguiente sección.
Entidades vs. tuplasComo ya hemos mostrado a lo largo de estos dos artí-culos, las posibilidades de recuperación de datos queofrece eSQL van mucho más allá de la estructura tabu-lar convencional del SQL tradicional. Al ejecutar unaexpresión de consulta de eSQL como la que se mues-tra en el listado 6, se obtiene como resultado una colec-ción de entidades como la que aparece en la tabla 2.
No obstante, en muchas ocasiones puede ser másconveniente recuperar una colección de tuplas (filas), quesería algo mucho más parecido a lo que obtendríamos alejecutar una sentencia SQL tradicional. Por esa razón,entre otras, eSQL soporta tipos de tuplas; de hecho, el
— consulta básica— OJO: devuelve una colección de TUPLA SFUTBOL2006Entities.Club— equivalente con SELECTSELECT VA LUE Club FROM FUTBOL2006Entities.Club
— otro equivalenteSELECT VA LUE C FROM FUTBOL2006Entities.Club A S C
Listado 4. Varias maneras de expresar una misma consulta
lenguaje ofrece un operador especializado, ROW, para laconstrucción de tuplas (ver ejemplo en el listado 7).
La cláusula VA LUE permite precisamente "aplanar"las entidades a filas. Si agregamos la cláusula VA LUE a laexpresión de consulta del listado 6 (obteniendo lasegunda de las consultas que se muestran en el listado4) y la ejecutamos, eSqlBlast nos mostrará algo simi-lar a lo que se ve en la tabla 3. Este aplanamiento seproduce implícitamente cuando utilizamos para la con-sulta una expresión básica en lugar de una expresiónde consulta SELECT.
Observe que siempre que se ejecute una expresiónde consulta con varias expresiones en la cláusula SELECT(como en los listados 1, 2 y 5), eSQL envuelve implí-citamente esos "campos" en tuplas. Éste es el compor-tamiento implícito también en el caso en que en la cláu-sula SELECT contenga una única expresión que no seadel tipo de ninguna de las entidades del modelo, comoen el listado 3, donde la expresión es una cadena decaracteres. Pero en este caso, el hecho de encapsular enuna tupla un único dato no aporta gran cosa; podría-mos preferir haber obtenido directamente una colec-ción de cadenas. Aquí también la cláusula VA LUE vienea nuestro rescate: tal encapsulamiento no se producirási la utilizamos, algo cuya comprobación dejamos pro- puesta al lector (Nota: aquí tal vez la salida de eSqlBlast
no sea muy informativa; le recomendamos que utilicenuestro programa de ejemplo, que puede descargar delsitio Web de dotNetManía).
ConclusiónEn este artículo hemos comenzado la presentaciónpráctica de las principales características de eSQL comolenguaje de consulta de modelos conceptuales. Aquínos hemos centrado en los aspectos fundamentales dellenguaje; en la próxima entrega, veremos los recursosque dan soporte a la utilización de las característicasmás avanzadas de los modelos, como la herencia y laspropiedades de navegación. ¡Hasta entonces!
— devuelve colección de entidades
SELECT Club FROM FUTBOL2006Entities.Club
Listado 6. Consulta eSQL que devuelve una colección deentidades
SELECT ROW(Club.Codigo, Club.Nombre, Club.Ciudad)
A S Club
FROM FUTBOL2006Entities.Club
Listado 7. Otra consulta eSQL equivalente a la del listado 4.
Tabla 2. Resultado de la consulta del listado 6.
Tabla 3. Resultado de la consulta del listado 4.
Bibliografía
Zorrilla, U., Hernández, O., “Consulta de modelos conceptuales con Entity SQL” (I), en dotNetManía nº56, enero de 2009.
Zorrilla, U., Hernández, O., Quintás E., “ADO.NET Entity Framework. Aplicaciones y servicios centrados endatos”, Krasis Press, 2008. En particular, el Apéndice B ofrece una referencia de Entity SQL.
Hernández, O., “C# 3.0 y LINQ”, Krasis Press, 2007.
Zorrilla, U., Hernández, O., “El Marco de Entidades de ADO.NET 3.5” (I-VII), en dotNetManía nº 44-50,enero-julio de 2008.
Documentación de Entity SQL en MSDN, en http://msdn.microsoft.com/en-us/library/bb399560.aspx.
Michailov, Z., post en el blog: http://blogs.msdn.com/esql/archive/2007/10/24/EntitySQL.aspx.
Cada vez los usuarios son más y más exigentes, ypor ello demandan cada vez más aplicaciones y máscomplejas. Los desarrolladores debemos afrontareste doble reto, siendo capaces de proporcionaraplicaciones mejores y más complejas en cada vezmenos tiempo. Evidentemente, éste es un proce-so global, que afecta a todo el ciclo de vida de unasolución de software. Por ello, las herramientasALM están cobrando un papel cada vez más impor-tante (ver el especial de dotNetManía de octubrede 2008 dedicado al tema). Pero no voy a hablarde ALM aquí, sino que me gustaría centrarme enlos retos concretos que esta situación implica cuan-do hablamos de interfaces de usuario. No en vano,la interfaz de usuario es el punto de conexión entreel usuario y la aplicación. Es un elemento crítico,y de su implementación depende en buena medi-da el éxito final de toda la aplicación.
Interfaces complejasLas aplicaciones actuales demandan interfaces deusuario complejas a nivel técnico, pero que a lavez sean sencillas de utilizar y de mantener. Quese adapten a cualquier tipo de usuario, y que tan-to usuarios expertos como inexpertos se sientana gusto utilizándola. En resumen, que la expe-riencia del usuario al utilizar la interfaz sea plena
y que nuestra aplicación sea usable por cualquierusuario.
El término interfaz compleja no quiere refe-rirse al aspecto visual o a la usabilidad, sino al hechode que cada vez resulta más complejo y difícil rea-lizar interfaces que permitan conjugar las crecien-tes posibilidades de una aplicación con la sencillezde uso y la usabilidad. Éste es el reto que debemossolucionar.
Un poco de historiaEl mecanismo habitual de desarrollar interfaces deusuario en .NET viene influenciado de los viejostiempos de Visual Basic. Es un patrón que consis-te en una clase contenedora (llamada comúnmen-te formulario) que contiene a los controles y todala lógica asociada a dichos controles. Por normageneral, el formulario se suscribe a los eventos delos controles que él contiene y realiza la lógica apro-piada en los métodos gestores de dichos eventos.La ventaja de este modelo de programación es quees sencillo, intuitivo y fácil de aprender. La des-ventaja es que al tener unidas la lógica y la pre-sentación, se vuelve más complejo el manteni-miento, tendiendo a colapsar en grandes proyectos,y se dificulta la separación del desarrollo entrevarios equipos.
La sencillez de una interfaz compleja
plataforma.net
Eduard Tomàstiene más de10 años
de experiencia en aná-lisis y desarrollo de
aplicaciones.Actualmente trabaja
como director de pro-yectos y arquitecto de
software en raona. Es MCSD.NET,
MCPD enaplicaciones Windows
y distribuidas,además de certificado
en UML y SCWCDen Java
En este artículo se hace una introducción a PRISM, el marco de trabajo parael desarrollo de aplicaciones visuales WPF propuesto por Microsoft Patterns& Practices para hacer posible la creación de aplicaciones más mantenibles yextensibles. También se presentan diversos patrones relacionados con PRISM,como Presentación separada e Inversión de control.
Es conocido ya desde hace algunosaños que una de las claves para desarro-llar interfaces complejas y que resultenmantenibles sin morir en el intento con-siste en desacoplar la presentación de lalógica asociada a dicha presentación. Lagente que viene de Visual C++6 ya lovenía haciendo desde los tiempos de lasMFC. Lamentablemente, Microsoft noincorporó ningún framework parecido aMFC en .NET. Posteriormente, duran-te los años que siguieron al lanzamientode .NET, la gente de Patterns & Prac-tices de Microsoft sí trabajó en este sen-tido, y nació CAB (Composite UI Applica-tion Block), que consistía en un montónde consejos y buenas prácticas sobrecómo desarrollar aplicaciones usandoWindows Forms, así como una libreríaque implementaba dichas buenas prácti-cas. Al cabo de un tiempo, vio la luzSCSF (Smart Client Software Factory), quecomplementaba a CAB con varias mejo-ras y añadidos a Visual Studio, conso-lidándose como una herramienta impres-cindible para el desarrollo de aplicacio-nes Windows Forms complejas.
Con la aparición de .NET Framework3.0 y WPF, volvemos a vivir una situaciónparecida a la que teníamos cuando salió.NET Framework: somos conscientes dela necesidad de herramientas que nos ayu-den en la creación de nuestras interfacescomplejas, pero Microsoft no nos pro-porciona ninguna, ya que CAB y SCSFno sirven para WPF1. Y como la historiatiende a repetirse, de nuevo nos llega lasolución de la mano de la gente de Pat-terns & Practices. CAL (Composite Appli-cation Layer) o PRISM, que vendría a sersu nombre "en clave", es la visión deMicrosoft sobre cómo debemos desarro-llar aplicaciones complejas usando WPF,así como una librería que implementadicha visión. PRISM no es “CAB paraWPF”: aunque muchos de los conceptosy patrones que existen bajo PRISM son
los mismos de CAB (puesto que la pro-blemática a solucionar es la misma),PRISM está especialmente diseñado paraWPF, además de que se aprovecha de todoel feedback que se ha ido generando sobreCAB durante los años en que esta tecno-logía ha estado en servicio.
A describir un poco dichas buenasprácticas es a lo que vamos a dedicar elartículo que tiene usted ahora entremanos.
Ventajas de una aplicacióncompuestaLlamamos aplicación compuesta (com-posite application) a aquella que está com-puesta por distintos módulos indepen-dientes y que colaboran entre sí. Lo deindependientes implica que pueden estardesarrollados por equipos diferentes. Cadauno de los módulos puede modificar suparte de la interfaz de usuario, aunquedebe garantizarse que el aspecto generalde la aplicación sea consistente.
Las principales ventajas de una apli-cación compuesta son:
1. Podemos separar fácilmente el desa-rrollo entre equipos distintos, yademás cada equipo puede concen-trarse en sus propias tareas.
2. Son aplicaciones extensibles: siemprees posible añadir nuevos módulospara las nuevas funcionalidades.
En lo sucesivo, veremos cómoPRISM hace posible la creación de apli-caciones compuestas y qué patronesintervienen en ello.
Introducción a PRISMUna aplicación PRISM se compone detres elementos principales:
1. El bootstrapper (o inicializador). Esel encargado de poner en marcha laaplicación. El bootstrapper carga losmódulos iniciales e inicializa el shell.También lanza ciertos servicios adi-cionales, como por ejemplo el servi-cio de logging.
2. El shell. Es el contenedor (ventana)principal de la aplicación. Contieneaquellos elementos de la interfaz deusuario que están visibles en todomomento. Por ejemplo, una barra demenú o un ribbon son candidatos aestar en el shell, ya que son elemen-tos que siempre están visibles en lainterfaz.
3. Uno o más módulos independientesque implementan las distintas fun-cionalidades de la aplicación.
Mi reino por una vistaHemos comentado que una aplicaciónPRISM se compone de varios módulosindependientes, y que cada módulo pue-de modificar la interfaz de usuario.
dotN
etM
anía
<<
21
1 Aunque con la salida de WPF la comunidad no se quedó quieta. Ante la necesidad de tener “un CAB para WPF”, nació el proyecto WPF Layerfor CAB (http://www.codeplex.com/wpfcab) para adaptar CAB a WPF. Posteriormente este proyecto quedó obsoleto y fue reemplazado por SCSFContrib (http://www.codeplex.com/scsfcontrib), que entre otras novedades incorpora una versión de CAB preparada para WPF.
PRISM está especialmentediseñado para WPF, y seaprovecha de todo el
¿Cómo se consigue esto en PRISM?Para ello, debemos explicar el primerode los patrones de diseño que imple-menta PRISM: el patrón Presentaciónseparada (Separated Presentation).
Presentación separada
Este patrón de diseño se puede resu-mir con la frase: asegurarse de que todo elcódigo que manipula presentación manipu-le solamente presentación, colocando toda lalógica de negocio y acceso a datos en áreasseparadas del programa [1].
Tener la lógica y la presentación jun-tas en una misma clase (el clásico “for-mulario”), hace que esta clase sea máscompleja, difícil de mantener y también(y eso es importante) difícil de testear.Además, se complica la reutilización decódigo entre “formularios” que requie-ren el mismo comportamiento. El patrónPresentación separada ataca estos pro-blemas haciendo que todo el código depresentación esté aislado en una clase quese conoce como vista (view). La vista esla encargada de mostrar los datos, perono tiene ninguna responsabilidad de lógi-ca de negocio. Es por así decirlo, com-pletamente tonta. ¿Y qué datos son losque muestra la vista? Pues los datos denuestro modelo (model). Así que tene-mos un modelo, que contiene unos datos,y una vista que muestra dichos datos.
En base a la relación entre la vista yel modelo y de donde esté el código quemaneja la lógica de negocio se determi-na qué variante del patrón Presentaciónseparada estamos usando. Hay varias,pero me gustaría comentar dos que sonmás usadas.
Model-View-Presenter (MVP)
En este patrón aparece el conceptode presentador (presenter). El presen-tador es la clase que contiene la lógicade negocio (recordad que no estaba enla vista) y quien comunica la vista conel modelo.
Existen, a su vez, dos variantes delpatrón MVP: MVP with Supervising
Controller y MVP Passive View. Enla primera variante (figura 1), la vista secomunica con el modelo a través de databinding simple. Este enlace a datos pue-de ser bidireccional, por lo que la vistapuede modificar el modelo. El presen-tador por su lado incorpora toda la lógi-ca de negocio, y permite modificar elmodelo y actualizar la vista en aquelloscasos que van más allá de un simple databinding.
En la variante MVP Passive View, nohay comunicación entre la vista y el mode-lo. En este caso, toda la comunicaciónentre la vista y el modelo debe realizarsea través del presentador (figura 2).
Model-View-ViewModel (MVVM)
En este patrón aparece el conceptode ViewModel, una clase que actúa defachada del modelo para la vista. ElViewModel (figura 3) monitoriza y secomunica con el modelo y lo “encapsu-la” en una interfaz más sencilla, a travésde la cual se comunica la vista (general-mente mediante data binding).
Aquí el ViewModel se encarga de rea-lizar todas aquellas transformacionesnecesarias en el modelo para que puedaser “entendido” por la vista y viceversa:cuando la vista actualiza un dato del View-Model, éste actualiza todos los datos rea-les del modelo. Generalmente, la vista yel ViewModel suelen estar comunicadosmediante data binding.
Regiones de PRISM
En PRISM, el shell (que implemen-ta la ventana principal) define una ovarias regiones. Una región de PRISMes una zona de la ventana principal don-de se pueden incrustar vistas. Los dis-tintos módulos proporcionan distintasvistas (utilizando cualquiera de los patro-nes Presentación separada que hemosdescrito), e incrustan las vistas en las dis-tintas zonas del shell. De esta manera,las vistas se integran todas juntas, dan-do al usuario una sensación de una inter-faz de usuario coherente.
Las regiones se definen en el XAMLdel shell utilizando la propiedad asocia-da RegionManager.RegionName.
¡Hola, PRISM!Para empezar a ver cómo funcionaPRISM e introducir algunos conceptos
nuevos, vamos a desarrollar una pequeñaaplicación PRISM. Y para no defraudara nadie, vamos a ver cómo sería el clási-co “Hello, world” utilizando PRISM.
Estructura del proyecto
Lo primero necesario para desarro-llar una aplicación PRISM es la propialibrería. Esta se puede descargar en [2].Los ensamblados que componenPRISM son:
Estrictamente hablando, los dos últi-mos ensamblados de la lista no formanparte de PRISM, sino de Unity (másadelante hablamos de él). PRISM yUnity van juntos muchas veces, aunqueno es obligatorio que sea así.
Usando Visual Studio, creamos unanueva aplicación WPF y le agregamoslas referencias a los ensamblados dePRISM. ¡Estamos listos para empezar!
Creación del shell
El primer paso es definir el shell denuestra aplicación. Recordad que el shelles la ventana principal de la aplicación,que contendrá aquellos elementos deinterfaz comunes y la definición de lasregiones donde los módulos incrustaránlas vistas que creen. Dado que Visual Stu-dio ya nos crea una ventana Window1,vamos a utilizar esta misma para definirnuestro shell (ver listado 1).
El código es muy simple: crea unarejilla con dos filas. En la primera filaincrusta una etiqueta con el texto “PRISMDemo”, y en la segunda fila un cuadro delista (llamado lstData). La clave está enlas dos líneas resaltadas: en la primera sim-plemente declaramos el espacio de nom-
bres cal para contener los elementosXAML que define PRISM. En la segun-da, declaramos una región de PRISM lla-mada List. En este caso, estamos defi-niendo una región de PRISM dentro deuna lista. Las vistas que agreguemos a estaregión se añadirán dentro de la lista.
Creación del bootstrapper
Una vez creado el shell, necesitamosel bootstrapper, que servirá de lanzadorde nuestra aplicación. El bootstrapper ini-cializa diversos componentes dePRISM, para terminar creando una ins-tancia del shell y pasándole el control.
Añadiremos al proyecto una nuevaclase llamada HelloPrismBootstrapper,cuyo código se muestra en el listado 2.
Si le sorprende el uso de Contai-ner.Resolve para crear el objeto Window1,tranquilo: eso es porque usamos el con-tenedor de Inversión de control Unity.Dentro de poco comentaremos lo másesencial de Unity, así que no se preocu-pe por ahora.
Finalmente, eliminamos el atributoStartupUri de A pp.xaml (porque el boots-trapper es quien creará el shell), y yapodemos ejecutar la aplicación. Deacuerdo, el resultado es un poco decep-cionante: simplemente nos muestra la
ventana principal y luego revienta conuna excepción (“IModuleEnumeratorcannot be null”).
Creación de un módulo
Tenemos el shell y tenemos el boots-trapper que nos lanza la aplicación. Elúltimo paso para tener una aplicacióntotalmente funcional es crear un módu-lo que nos incruste alguna vista en laregión que hemos definido en nuestroshell.
Un módulo de PRISM es una cla-se que implementa la interfaz IModu-le (que contiene un solo método lla-mado Initialize). Dado que unmódulo es una clase, un mismoensamblado puede contener variosmódulos de PRISM. Los módulos sonquienes crean las vistas (y los objetosadicionales, tales como presentado-res) y las colocan en las regiones delshell. ¿Y quién carga los módulos?Pues el bootstrapper. Para ello deberedefinirse el método GetModuleEnu-merator, y desde este método devol-ver una instancia de IModuleEnumera-tor, que es la interfaz que usa PRISMpara cargar los módulos. Para ello,añadiremos al bootstrapper el métodoque se muestra en el listado 3.
La clase StaticModuleEnumeratorimplementa IModuleEnumerator, y sumétodo A ddModule nos permite cargar unmódulo. Existen varios IModuleEnumera-tor ya listos para utilizar en PRISM (porejemplo, para añadir todos los módulosque estén en los ensamblados de un direc-torio o usar un fichero de configuración),y también podemos crear nuestras pro-pias implementaciones.
El siguiente paso consiste en crearel módulo. Para ello, añadimos una cla-se llamada HelloModule en nuestro pro-yecto, con el código que se muestra enel listado 4.
Observe que el módulo implementaIModule y en el método Initialize acce-de al RegionManager de PRISM paraincrustar en la región Listdos vistas idén-ticas del tipo HelloView.
Por último, solo nos queda imple-mentar la vista HelloView. En este casoes una vista extremadamente simple,que contiene solamente una etiqueta(listado 5).
Si ahora ejecutamos la aplicación,veremos la ventana del shell, y dentrodel cuadro de lista dos elementos Hello-View. ¡Ya hemos creado nuestra prime-ra aplicación PRISM!
protected override IModuleEnumerator GetModuleEnumerator(){return new StaticModuleEnumerator().A ddModule(typeof(HelloModule));
}
Listado 3. Método GetModuleEnumerator del bootstrapper
Inversión de control (Inversion of Con-trol, IoC) es una técnica destinada a eli-minar las dependencias entre clases ypor lo tanto conseguir una arquitectu-ra más débilmente acoplada. Existen dospatrones principales dentro de IoC,Localizador de servicio e Inyección dedependencias, y dado que ambos se usanampliamente en PRISM, vamos a echar-les un vistazo.
Para poder usar ambos patrones, esnecesario disponer de lo que se conocecomo un contenedor IoC. PRISM pue-de funcionar con cualquier contenedorIoC existente2, pero “de serie” viene pre-parado para usar Unity, que es el con-tenedor IoC de código abierto deMicrosoft.
Localizador de servicio
Imagine una situación en que unaclase (CA ) utiliza un servicio, implemen-tado en la clase S1. En este caso, la cla-se CA tiene una dependencia directa deS1. Para cambiar dicha dependencia(por ejemplo, ha salido una versión dis-tinta de S1 implementada en la clase S1b),tenemos que cambiar nuestro códigofuente.
El uso de interfaces no soluciona estadependencia, puesto que terminaremosteniendo un código parecido al del lis-tado 6. En este caso, aunque la clase usela interfaz I1, sigue habiendo una depen-
dencia directa entre CA y la clase S1, debi-do al new. Y hacer que el constructorreciba un parámetro de tipo I1 en lugarde crear el objeto, no nos soluciona elproblema: simplemente mueve ladependencia a otra clase (aquella quecrea objetos CA ).
El patrón Localizador de servicio(Service Locator) soluciona este proble-ma mediante el uso de un objeto inter-medio (el localizador de servicio), quees quien obtiene las instancias de los ser-vicios. Como se muestra en la figura 4,la clase “pide” un servicio que imple-mente la interfaz I1 al localizador deservicio, y éste es el encargado de devol-ver una instancia del tipo adecuado. Laresolución se realiza en tiempo de eje-cución mediante las reglas que puedatener configuradas el localizador (lo queimplica que cambiando dichas reglaspueden obtenerse objetos de distintasclases). Con ello eliminamos todas lasdependencias de nuestra clase de los ser-vicios, sustituyéndolas por una soladependencia del localizador de servicio(y de la interfaz I1, pero no hay depen-dencias entre la clase CA y las clases deservicio S1 y S1b).
Inyección de dependencias
El patrón Inyección de depen-dencias (Dependency Injection) se basa entrasladar todas las dependencias al con-tenedor de IoC, para que sea éste quiencree los objetos de los tipos necesarios.Se puede ver como una extensión del
patrón Localizador de servicio, dondeel contenedor de IoC rellena todos losparámetros necesarios para crear unobjeto determinado.
Por ejemplo, dada la clase del lista-do 7, cuando creemos un objeto de laclase CA , el contenedor IoC es el encar-gado de dar valor al parámetro s1 delconstructor, obteniendo una instanciade la clase correspondiente.
El contenedor Unity
Unity es el contenedor IoC deMicrosoft, y por lo tanto ofrece sopor-te completo para Localizador de servi-cio e Inyección de dependencias. La cla-se UnityBootstrapper (de la cual derivanuestro bootstrapper) es la encargada decrear el contenedor de Unity en la pro-piedad Container.
Las operaciones básicas de Unity son:
• Registrar un mapeo entre una inter-faz I1 y un objeto de una clase S1 queimplemente I1 (método RegisterTy-pe<Interfaz, Clase>). Con ello, cuan-do el contenedor IoC requiera unobjeto que implemente I1, devolveráuna instancia de la clase S1.
• Pedir una instancia de un objeto queimplemente I1. Unity nos devolveráun objeto de la clase que tenga elmapeo correspondiente (métodoResolve<Interfaz>).
• Pedir una instancia de un objeto deun tipo determinado. Unity creará unobjeto de dicho tipo, resolviendotodos los parámetros necesarios delconstructor (método Resolve<Clase>).
¿Recuerda la llamada a Contai-ner.Resolve<Window1>() que usábamosen el bootstrapper para crear un nuevoshell? Con esa llamada le estamos indi-cando a Unity que nos cree una nuevainstancia de la clase Window1 y que sumi-nistre al constructor todos los objetosnecesarios (si los hubiese).
O por ejemplo, si revisa el código dela clase HelloModule, verá que el cons-tructor tiene dos parámetros (IUnity-Container y IRegionManager). Quien ins-tancia los módulos es la clase StaticMo-duleEnumerator. Para crear un objeto deltipo HelloModule, se utiliza el código dellistado 8. Como puede observar, se lla-ma al método Resolve pasándole un obje-to Type con la información del tipo a cre-ar (en nuestro caso, el parámetro type estypeof(HelloModule))3.
MVP con Unity
Vamos a ver un ejemplo de cómousar el patrón MVP (Model-View-Pre-
senter) explicado anteriormente usandoPRISM y Unity. Para ello, partiremosdel ejemplo HelloPrism anterior.
Primero, creamos la interfaz quedebe soportar el presentador y nuestraclase de presentador (listado 9).
Ahora vamos a configurar Unity,para que, cuando se le pida un objetodel tipo IHelloPresenter, devuelva unobjeto de la clase HelloPresenter. Unbuen lugar para hacer esto es cuando secarga el módulo HelloModule. Para ello,programaremos el método Initializesegún se muestra en el listado 10.
class CA{private I1 _s1;
// El parámetro s1 lo incrusta el // contenedor IoCpublic CA (I1 s1){this._s1 = s1;
3 PRISM no utiliza Unity directamente, ya que soporta cualquier contenedor IoC. Para ello, define una interfaz llamada IContainerFacade, y es elbootstrapper quien se encarga de crear una clase que implemente IContainerFacade y que use un contenedor IoC concreto. La claseUnityBootstrapper (incluida en PRISM) hace este trabajo por nosotros si queremos usar Unity.
Ahora solo nos queda pasarle el pre-sentador a la vista, y para ello confiare-mos en el patrón Inyección de depen-dencias. Añadimos al constructor de lavista un parámetro de tipo IHelloPre-senter, como muestra el listado 11.
Cuando el módulo HelloModule creeun objeto HelloView (usando el métodoResolve), Unity automáticamente cre-ará un objeto HelloPresenter y lo usarácomo el parámetro para el constructorde la vista.
Como podéis ver, Unity no nos fuer-za a ningún patrón específico de pre-sentación separada, y sí nos da todas lasherramientas para que implementemoslo que deseamos de forma fácil.
Eventos y comandosHemos visto lo más básico de PRISM:cómo crear vistas usando el patrón MVPy cómo incrustarlas en las zonas que defi-ne el shell. Vamos a ver ahora el últimopunto necesario para poder construir unaaplicación: cómo se comunican entre ellaslas distintas vistas.
El sistema de eventos
Dado que las vistas pueden estar cre-adas por módulos que son indepen-
dientes entre sí, es necesario el uso deun sistema de comunicación tambiéndesacoplado, en el que una vista (o pre-sentador) pueda notificar a cualquierotra vista de que ha sucedido algunaacción en concreto, y también recibirnotificaciones emitidas por cualquierotra clase de la aplicación. Para dar unasolución a este problema, PRISM utili-za un sistema de eventos basado en elpatrón Publicador–Suscriptor (Publis-her-Subscriber).
El patrón Publicador–Suscriptor
Este patrón (figura 5) se basa en laidea de que cuando una clase quierecomunicar que ha sucedido un evento lopublica, y quien está interesado en reci-bir un evento se suscribe a él. El publi-cador no sabe quiénes son sus suscripto-res, y un suscriptor tampoco conocequién ha publicado un determinadoevento. Vendría a ser algo parecido a unalista de correo, en la que enviar un men-saje implica que lo recibirán todos aque-llos que estén suscritos a la lista, aunquequien envía el mensaje no tiene porqueconocer quiénes lo van a recibir.
Desarrollando con el sistema deeventos de PRISM
El sistema de eventos de PRISMestá implementado en una clase queimplementa la interfaz IEventA ggrega-tor. El bootstrapper registra un singleton
de esta clase en el contenedor IoC, porlo que siempre que pidamos al conte-nedor un objeto que implemente IEventA ggregator recibiremos el mismo,durante todo el ciclo de ejecución deaplicación.
Lo primero que hay que hacer es cre-ar una clase que defina el tipo de even-to que queremos publicar o al que nosqueremos suscribir. Para ello, hay quederivar de la clase CompositeWpfEvent<TPayload>. El parámetro genérico TPay-load indica el tipo de datos que contie-ne nuestro evento. En terminologíaPRISM, los datos de un evento se cono-cen como carga adicional (payload).Podemos tener varios eventos con elmismo tipo de carga adicional.
Por ejemplo, para definir el eventode tipo HelloEvent y cuyos datos seránuna cadena, definimos la clase HelloE-vent del listado 12.
Para poder publicar o suscribirnosa un evento de este tipo, tenemos queobtener una referencia al agregador deeventos de PRISM (IEventA ggregator),a través del contenedor IoC. Por ejem-plo, si queremos que el presentador ten-ga acceso al agregador de eventos,
public IHelloPresenter Presenter { get; private set;
podemos añadir un parámetro IEven-tA ggregator al constructor del presen-tador, y de este modo nos lo rellenaráel contenedor IoC (listado 13).
Para suscribirnos a un tipo de even-to, invocamos el método GetEvent<T>,donde T es el tipo de evento al que nosqueremos suscribir, e invocamos Subs-cribe sobre el objeto que se nos devuel-ve (listado 14).
El método Subscribe espera undelegado con el código a ejecutar cuan-do se reciba un evento del tipo indica-do. El delegado debe tener un pará-metro cuyo tipo sea el tipo de la cargaadicional del evento (en nuestro caso,el tipo de la carga de HelloEvent esstring). El método Subscribe devuelveun token de suscripción que nos sirvepara poder cancelar la suscripción encualquier momento (usando el méto-do Unsubscribe).
Para publicar un evento, basta conllamar al método Publish en lugar deSubscribe (listado 15), pasándole unparámetro que será la carga adicionaldel evento (en el caso de HelloEvent, elmétodo esperará una cadena).
Comandos
Un comando es parecido a un even-to, en el sentido de que es una notifica-ción de que ha ocurrido algún hecho. Sediferencia de un evento en que un even-to está ligado a uno o más elementos dela interfaz de usuario que lo invocan; elcomando, por su parte, puede estar acti-vado o desactivado, lo que activa o desac-tiva todos los elementos de la interfaz deusuario ligados a él.
El uso de comandos permite rea-provechar lógica que se invoca desdevarios elementos de la interfaz de usua-rio; elementos que pueden a su vez serproporcionados por módulos comple-tamente independientes entre sí.
PRISM soporta comandos locales,que se usan para comunicar una vistacon su presentador (o su ViewModelasociado), y comandos globales, acce-sibles en toda la aplicación.
Vamos a ver rápidamente cómo fun-cionan los comandos, empezando porlos comandos locales y continuando conlos globales. Para declarar un comandolocal, lo más habitual es declarar un obje-
to de la clase DelegateCommand<T>, don-de T es el tipo de datos que maneja esecomando. Por ejemplo, vamos a añadiruna vista (y un presentador) adicionales.El código XAML de la vista (HelloView2,listado 16) es trivial.
Simplemente declaramos tres con-troles (una etiqueta, un cuadro de tex-to para introducir datos y un botón).El código C# asociado a la vista (lista-do 17) se limita a invocar el comandoque su presentador le expone a travésde la propiedad Hello2Command. Recuer-de que un buen sitio para que la vistareciba su presentador es en el cons-tructor; así Unity creará el presenta-dor de forma automática.
Luego declaramos la interfaz y laclase de nuestro nuevo presentador (lis-tado 18). El presentador crea un Dele-
public HelloPresenter(IEventA ggregator evtA g)
{// Nos guardamos el agregador // de eventosthis.evtA g = evtA g;
gateCommand<string>, pasándole comoparámetro un delegado con la acción arealizar cuando se invoque el comando.Dicho delegado acepta un parámetro,cuyo tipo depende del tipo genérico. Eneste caso, dado que tenemos un Delega-teCommand<string>, el delegado esperauna cadena.
Para que todo nos funcione, ya solonos quedan dos detalles: en el módulo(HelloModule) añadir el mapeo de IHe-lloPresenter2 a Unity, y crear una ovarias vistas de tipo HelloView2 y aña-dirlas a la región PRISM. Con esto, aca-bamos de crear un comando local, quenos permite una comunicación entre lavista (HelloView2) y su presentador deuna forma totalmente desacoplada.
Veamos ahora cómo podríamos cre-ar un comando global, que fuese invo-cado por varias vistas distintas. Habi-tualmente, los comandos globales seexponen como miembros estáticos, deuna clase generalmente estática (listado19). Suelen ser de tipo CompositeCommand,
que como su nombre indica es un coman-do compuesto de otros comandos.
Observe que al comando global nole pasamos ningún delegado, como enel caso de DelegateCommand<T>. En sulugar, rellenaremos este comando conotros comandos. Por ejemplo, vamos ahacer que desde la vista original queteníamos (HelloView) podamos invocaral comando Hello2Command que definíael presentador HelloPresenter2.
Para ello, simplemente en el cons-tructor de HelloPresenter2 tenemosque añadir al comando compuestoMyGlobalCommand el propio comandoHello2Command, mediante el métodoRegisterCommand (listado 20). Y enton-ces ya podríamos, por ejemplo, añadirun botón a la vista HelloView originaly asociarle un método para gestionarlos clics sobre ese botón que tenga elcódigo del listado 21.
¡Más simple imposible! Cuando sepulse el nuevo botón de HelloView, seejecutará el comando global. Fíjese que,dado que cada HelloPresenter2 añade supropio comando Hello2Command al
comando global, si se añaden variasHelloView2 a la región PRISM, comocada una tiene su propio presentador, alinvocar el comando global se verá másde un cuadro de mensaje.
Por último, recuerde que los coman-dos PRISM implementan la interfazICommand. ¡Esto significa que se puedenasignar directamente desde XAML! Sitomamos de nuevo la vista HelloView yeliminamos el evento Click del nuevobotón que hemos creado, y en su lugarañadimos el atributo Command al códigoXAML del botón para que quede comose muestra en el listado 22, el efecto seráexactamente el mismo que antes.
¿Y ahora qué?
Con esto se termina este artículo, en elque hemos explorado un poco los patro-nes utilizados para crear aplicaciones com-puestas y cómo implementarlos en WPFutilizando PRISM. Si le interesa el temay quiere profundizar en él, la mejor mane-ra es descargar el código fuente, la docu-mentación y los ejemplos de PRISM, des-de su sitio oficial [2]. El paquete incluyeuna implementación completa de unaaplicación de ejemplo, así como variosejemplos detallados de cada uno de lospatrones que aquí hemos enumerado.
ReferenciasFowler, Martin. “Separated Presentation”. Enhttp://martinfowler.com/eaaDev/Sepa-ratedPresentation.html, junio de 2006.
Composite Application Guide for WPFand Silverlight. En http://www.code-plex.com/CompositeWPF.
[1]
[2]
public interface IHelloPresenter2{DelegateCommand<string>
Hello2Command { get; }}
public class HelloPresenter2 : IHelloPresenter2
{public DelegateCommand<string>
Hello2Command { get; private set;
}
public HelloPresenter2() {Hello2Command =new DelegateCommand<string> (
x => MessageBox.Show(x+”!”));
}}
Listado 18. Interfaz y clase del presentador
public static class HelloCommands{public static CompositeCommand
En este artículo vamos a explicar un escenario nodemasiado típico, pero que viene repitiéndose cadapoco tiempo en los foros públicos, y con el que elautor se ha encontrado, también frecuentemente,a ambos lados de la situación: tanto creando elescenario como usándolo.
A casi cualquier programador le habrán sumi-nistrado una DLL, realizada generalmente en Co C++, para ser utilizada desde un lenguaje .NET.El ejemplo típico es el de aquellas funciones deWin32/Win64 que no tienen contrapartida den-tro de la biblioteca .NET; pero también puedeocurrir que nos suministren bibliotecas de terce-ros en formato DLL, y en este último caso la situa-ción se presenta algo más difícil ya que, si biensabemos fehacientemente que las funciones Win32deben funcionar, no podemos estar tan seguros delo que nos han dado.
Vamos, pues, a presentar una DLL realizadaen C++ con una interfaz pública en C, que sueleser lo habitual. Aunque se suministra el códigofuente de la misma, no vamos a entrar en ningúndetalle sobre su implementación; la trataremoscomo una caja negra, y solo hablaremos de su par-te pública, ya que será lo que vamos a enlazar. Elsiguiente paso consistirá en crear un ensambladoen C# que hará de interfaz entre la DLL nativa y
los programas que se vayan a realizar con ella, delo que presentaremos un ejemplo. De este modo,solo tendremos que hacer lo difícil una vez, ypodremos usar el conjunto de ambas DLL cuan-do queramos. Y luego construiremos otro ensam-blado, esta vez en C++/CLI, para mostrar cómoenvolver de forma avanzada una biblioteca exis-tente mediante un ensamblado en modo mixto,demostrando así una de las principales utilidadesde C++/CLI dentro del universo .NET. Asimis-mo, veremos algunos otros temas relacionados conla interoperabilidad que no están correctamentedocumentados o cuya documentación es insufi-ciente.
Para poder aprovechar el ejemplo, el lectordebe tener instalada al menos la versión Estándarde Visual Studio 2008 con soporte para C++, paraasí poder compilar y meterse dentro del código enC++ a través del depurador de Visual Studio. Noobstante, no es imprescindible hacerlo, aunque sírecomendable.
La DLL nativaNo vamos a complicarnos mucho la vida con esteprograma, que será un ejemplo totalmente artificial,
Interop en C# y C++/CLI Dos puntos de vista de un mismo concepto
plataforma.net
Rafael Ontivero tienemás de 20 años de expe-riencia como programa-dor en múltiples lengua-
jes y entornos y comoresponsable de equipos
de desarrollo. Actualmen-te es director técnico
para España de la multi-nacional Suzo STC.
La interoperación entre código manejado y no manejado es una de lastareas que se presentan frecuentemente a cualquier programador .NET.Aquí se describen detalladamente dos enfoques diferentes: el primero,haciendo uso de los recursos que ofrecen para ello C# y .NET; el segun-do, utilizando C++/CLI, una extensión de C++ diseñada con la intero-perabilidad como uno de sus objetivos centrales.
pero que sin embargo contemplará lasacciones más comunes dentro de la inte-roperabilidad entre código nativo ymanejado.
Ya que los tipos básicos se traducendirectamente, es decir, existe unacorrespondencia directa entre, porponer un ejemplo, un bool nativo y unbool manejado, y lo mismo ocurre conlos enteros y otros, nuestra bibliotecano va a utilizar directamente ningunode ellos. En su lugar, vamos a emplearuna estructura que contendrá dos valo-res numéricos para representar unnúmero complejo y una cadena termi-nada en cero, algo muy típico de Win32y C; también emplearemos una enu-meración y dos funciones de respuesta(callbacks). La tarea de la DLL nativaserá la de realizar un cálculo sobre dichonúmero complejo y avisarnos de su fina-lización mediante uno de los callbacks,que nos devolverá el cálculo en forma-to numérico y en cadena de textomediante la estructura citada. El segun-do callback se utilizará para avisarnos sise produce una condición de error, y laenumeración contendrá el código delerror ocurrido. El ejemplo es suma-mente artificial, pero resulta fácil deimplementar y cubre todas las carac-terísticas que queremos demostrar.
El listado 1 expone la API públicade la DLL. El código representa unejemplo típico de cómo se implemen-ta una DLL nativa y se expone su inter-faz a otros lenguajes o aplicaciones.Dada la similitud con C#, no vamos aexplicar nada sobre la misma, ya que loscomentarios son suficientes.
Antes de comenzar a explicar cómorealizar el código, debemos centrarnosen algunos detalles previos que no seencuentran debidamente documentados.
El tema de las arquitecturasUn ensamblado .NET puede estarcompilado bajo tres arquitecturas dife-rentes: x86, x64 y AnyCPU1. Si com-pilamos un ensamblado con la arqui-
tectura x86, se ejecutará en cualquierWindows de 32 bits, y también en losde 64 bits, pero siempre como códigode 32 bits. Si lo hacemos con x64, dichoensamblado sólo podrá ejecutarse bajoWindows de 64 bits, generando una
excepción en los de 32. Por otra parte,la arquitectura AnyCPU es más poten-te: permite ejecutar un ensamblado ensu arquitectura nativa, es decir, comocódigo de 32 bits en un Windows de 32bits, y como código de 64 bits en un
/**** Estamos definiendo una estructura que representa a un número complejo*/
typedef struct{
double real; // Parte realdouble imag; // Parte imaginariaTCHA R *szFormateado; // Puntero a una cadena terminada en cero
} tagComplejo;
/***** A quí definimos los posibles errores que se pueden producir al trabajar* con números complejos.*/
typedef enum{
ComplejoErrorNoError = 0, // No es un errorComplejoErrorDivCero, // Se produjo una división por ceroComplejoErrorOtro=-1, // Otro error
} enuError;
/***** Estas dos definiciones nos ayudan a mantener el código claro. Definen * dos punteros a función y simplifican el prototipado de otras funciones.*/
// Puntero a función que recibe una estructura del tipo tagComplejotypedef void (__stdcall* fncComplejoCalculado)(tagComplejo);
// Puntero a función que recibe una estructura y una enumeración.// Si se retorna false, la DLL forzará el cierre de la aplicación typedef bool (* fncComplejoError)(tagComplejo,enuError);
// Instala los callbacks en la DLL para luego poder llamar extern “C” DLLNA TIVA _A PI void ComplejoInstalaCallbacks(
// Calcula el inverso de dos complejosextern “C” DLLNA TIVA _A PI void ComplejoInverso(
tagComplejo c1,tagComplejo c2);
// Devuelve una cadena con el complejo en forma polarextern “C” DLLNA TIVA _A PI int ComplejoPolar(tagComplejo,TCHA R *szPolar);
Listado 1. El fichero de cabecera de la DLL nativa
1 Realmente existe una arquitectura más, Itanium, pero no vamos a hablar de ella aquí por el poco uso que tiene. Sin embargo, todo lo visto aquíes perfectamente válido también para ella.
Windows de 64 bits. De todas formas,estas consideraciones son teóricas, yaque por desgracia una misma aplicaciónfunciona diferente según en qué arqui-tectura se haya compilado, llegandohasta el punto de funcionar mal aunqueel código sea el mismo y esté correcto.
Cuando nuestra aplicación es .NETpura no hay problemas, pero cuando tie-ne ensamblados mixtos, es necesario serextremadamente cauteloso con las arqui-tecturas. Imaginemos que tenemos unaDLL nativa de 32 bits (nuestro caso), yque nuestra aplicación .NET que la uti-liza ha sido compilada bajo x64: la ejecu-temos donde la ejecutemos, generará unaexcepción en tiempo de ejecución, ya queespera una DLL nativa de 64 bits. Aho-ra compilemos nuestro programa .NETbajo AnyCPU. En este caso, la aplicaciónfuncionará cuando la ejecutemos en unWindows de 32 bits, pero fallará estrepi-tosamente cuando lo hagamos sobre unode 64 bits. El motivo es muy sencillo: elensamblado .NET se ejecutará en unentorno de 64 bits y llamará a una DLLnativa que espera que sea también de 64bits. Como ésta es de 32, lanzará unaexcepción. Finalmente, bajo un Windowsde 32 bits, la aplicación se ejecutará comouna aplicación de 32 bits y cargará de for-ma satisfactoria la DLL.
El lector puede preguntarse quéocurre cuando un ensamblado cargamediante Interop una DLL de Win-dows en según qué arquitectura. Si laaplicación está compilada medianteAnyCPU, cargará las DLL correspon-dientes y correctas de cada sistema y conla anchura de bits correspondiente (32ó 64 bits), ya que el sistema tiene ambasversiones y sabe qué hacer en el caso desus propias DLL. Pero si dicha aplica-ción está compilada mediante x86 y seejecuta en un Windows de 64 bits, car-gará entonces las DLL de 32 bits y seejecutará como una aplicación de 32 bitsbajo la capa de SysWow64.
Debemos, pues, tener en cuenta estasconsideraciones a la hora de hacer unensamblado mixto que use DLL nativas.
Es decir, si estamos importando una DLLde 32 bits, nuestro programa deberá estarcompilado bajo x86, y si estamos impor-tando una DLL de 64 bits, deberemoshacerlo bajo x64. El modo AnyCPU sólodebe utilizarse cuando dispongamos deun instalador que nos coloque la DLLnativa correcta según cuál sea el sistemaoperativo en el que estemos ejecutando2.Evidentemente, en este caso perdemos laposibilidad de ejecutar nuestra aplicacióncomo aplicación de 32 bits dentro de unsistema de 64.
Las rutas de los proyectos y elcódigo mixtoOtro elemento a tener en cuenta a lahora de crear un proyecto mixto son lasrutas de los ficheros intermedios queVisual Studio asigna por defecto. Cuan-do uno crea un proyecto nativo en unasolución, Visual Studio coloca los eje-cutables en una subcarpeta dentro de lamisma carpeta que el proyecto; perocuando se añade uno más (nativo), elentorno mueve la carpeta de los fiche-ros finales a una ruta que cuelga direc-tamente de la carpeta en donde está lasolución, uniendo todos los ficherosfinales en un mismo lugar, ya que sesobreentiende que una solución multi-proyecto ha de disponer todos los eje-cutables y DLL en un mismo lugar.
Desafortunadamente, el IDE secomporta de forma diferente cuando setrata de proyectos manejados: cada unode ellos tiene su carpeta final dentro dela del proyecto, y la solución adoptadaes que cuando se añade una referenciaa un proyecto desde otro, el IDE copiala dependencia entre carpetas, llenan-do de ficheros repetidos toda la solu-ción (y si encima estos ficheros songrandes, se añade más sobrecarga alproceso de generación de binarios).
Por ello también es necesario, omejor dicho, recomendable, cambiar laruta final de los ensamblados .NET a lamisma carpeta que los nativos. Para ello
nos vamos a las opciones de nuestro pro-yecto .NET, y en la pestaña “Build”, cam-biamos la ruta de “Output Path” por ladeseada, como se muestra en la figura 1.
Otro aspecto interesante es la posi-bilidad de bucear dentro del códigofuente nativo (si lo tenemos) desde unprograma .NET, para ver cómo fun-ciona nuestra aplicación y observarpotenciales problemas con Interop. Enun proyecto C#, debemos marcar lacasilla “Enable unmanaged code debug-ging” dentro de la pestaña “Debug”(figura 2).
2 Y no debemos olvidarnos de ejecutar pruebas en todos los escenarios posibles, ya que como hemos dicho más arriba, las compilaciones AnyCPUno siempre funcionan como esperamos que lo hagan.
Figura 1. Estableciendo el directorio de salida
Figura 2. Activando la depuración decódigo no manejado
El lector puede comprobar cómo elautor ha configurado todo esto en loslugares citados de la solución de ejem-plo3. Además, podrá observar que lasolución tiene nada más y nada menosque cinco proyectos. DLLnativa es la pro-pia DLL nativa del ejemplo, la base detodo lo que estamos viendo. Luegotenemos el proyecto test_nativa, quees un ejecutable nativo de consola queverifica el funcionamiento de la DLL.WrapDLL_CS es el ensamblado que envuel-ve a la DLL nativa, desarrollado en C#mediante Interop por atributos, mien-tras que UseDLL_CS es el programa rea-lizado en C# que utiliza el ensambladoWrapDLL_CS. WrapDLL_CPP es el ensambla-do en modo mixto realizado enC++/CLI que envuelve, de nuevo, aDLLnativa, y que nos servirá para deta-llar las diferencias entre éste y el envol-torio realizado en C#. Finalmente,UseDLL_CPP, en contra de lo que su nom-bre indica, es el mismo proyecto queUseDLL_CS (escrito en C#), pero que eneste caso usa el ensamblado realizadoen C++/CLI.
Opciones comunes para laimportación de DLLAntes de entrar en los ejemplos, debe-mos dar una serie de indicaciones gene-rales sobre el concepto de interopera-ción con código nativo desde C#.
Una firma de importación típica esla que se detalla a continuación:
La línea entre corchetes indica queestamos especificando algún tipo deatributo para el elemento que se defi-ne en la siguiente línea. En nuestrocaso, le estamos diciendo al compila-dor que el método de abajo procede de
una importación desde una DLL lla-mada DLLnativa.DLL. Este atributo poseemás parámetros, como se verá más ade-lante (y no los explicaremos todos).
Luego viene la firma de la funciónpropiamente dicha, que debe ser decla-rada externa y estática. El declararlapública solo dependerá de si queremosque sea visible desde fuera de nuestroensamblado (en general, se aplican lasreglas de visibilidad normales de C#).
A partir de este momento, ya pode-mos usar dicha función como si se tra-tara de una escrita en C#, con la salve-dad, claro está, de que se trata de unallamada a algo externo a nuestro códi-go y debemos seguir ciertas reglas.Tampoco debemos esperar un rendi-miento extraordinario en la llamada almétodo, sobre todo si pasamos datosde gran tamaño, ya que el motor detiempo de ejecución tendrá que copiarvarias veces dichos datos entre la partenativa y manejada. Si el lector quieremaximizar el rendimiento, no le quedaotra opción que utilizar C++/CLI enmodo mixto y ser cuidadoso en cómorealiza las llamadas.
Estructuras y enumeracionesEquiparar estructuras nativas y maneja-das es relativamente fácil mientras nointervengan algunos aspectos oscuros,como punteros a void, cadenas termina-das en cero y cosas así. En nuestro caso,la estructura tagComplejo contiene dos
valores en coma flotante y un puntero acadena terminada en cero. De momen-to, no vamos a entrar en este último valory lo vamos a definir como un IntPtr, esdecir, como un tipo destinado a repre-sentar un puntero o un handle.
La primera duda que nos surge essi las estructuras de C# son equivalen-tes directamente a las de C/C++. Aun-que en principio es así, debemos teneren cuenta que es necesario mapear lostipos .NET con los nativos, de mane-ra que la disposición binaria de ambasestructuras sea la misma.
Las enumeraciones (que en .NETson tipos completos, mientras que enC/C++ son constantes sustituidas porsu valor numérico) también son muyfáciles de convertir, ya que tan solo ten-dremos que copiar sus valores a nues-tro código envolvente. Lo único quetenemos que tener en cuenta es quedebemos conservar los valores numé-ricos adecuados, lo que en general nosuele ser difícil. En nuestro caso, la con-versión es trivial:
Punteros a cadenas terminadas en ceroVamos a comenzar con la parte más sen-cilla de todas, y también bastante típi-ca dentro del mundo Win32/Win64.La función nativa ComplejoPolar recibedos parámetros: un número complejosegún la estructura anteriormente cita-da y una cadena terminada en cero, quela función deberá rellenar con el núme-ro equivalente expresado en notaciónde coordenadas polares. El valor devuel-to es el número de bytes asignados enla cadena.
3 No obstante, dependiendo de la configuración del lector, quizás estos parámetros hayan desaparecido y tengan que ser introducidos de nuevo amano. Recuérdese, pues, que si su proyecto le da una excepción de fichero no encontrado, lo más probable es que las rutas hayan vuelto a susvalores por defecto.
[DllImport(“DLLnativa.dll”)]
public static extern int ComplejoPolar(NumeroComplejo c, IntPtr cadena);
public enum ComplejoError{
// No es un error.ComplejoErrorNoError = 0, // Se produjo una división // por ceroComplejoErrorDivCero,// Otro errorComplejoErrorOtro = -1,
En Win32 es habitual la existenciade funciones que han de devolver orellenar cadenas terminadas en cero delongitud variable y desconocida hastael momento de su ejecución. El segun-do parámetro de nuestra función Com-plejoPolar funciona de esta forma. Esdecir, primero debemos hacer una lla-mada pasando un valor nulo, para quela función evalúe su funcionamiento ynos devuelva el tamaño de la cadenaasignada y, una vez conozcamos cuán-tos bytes son necesarios, volvemos arealizar la llamada, pasándole esta vezuna cadena del tamaño adecuado.
El primer paso consiste en impor-tar el método dentro del ensambladode envoltorio que va a hacer de puen-te entre nuestra DLL nativa y el restode código en C#. El prototipo median-te interoperación por atributos es:
Podemos observar dos parámetrosinteresantes que acompañan la defini-ción del atributo. Con la parte CharSet= CharSet.Unicode, le estamos indican-do al compilador que la DLL nativa hasido compilada mediante Unicode, porlo que nuestras cadenas van a ser de esetipo, en oposición a CharSet.A nsi, queindicaría que el tipo de la cadena seríachar en lugar de wchar_t. El efecto máscomún si nos equivocamos de codifica-ción sería recibir un resultado incohe-rente o que se dispare una excepciónpor desbordamiento de búfer.
El siguiente parámetro representael convenio de llamada, no menosimportante que lo anterior. Cuando lla-mamos a un método o a una función,el compilador ha de saber qué hacer conlos parámetros pasados y devueltos; estotiene lugar en la pila local del progra-
ma, y dependiendo del convenio de lla-mada, será tarea del método llamanteo del llamado recuperar los parámetrospasados y el valor devuelto, de tal for-ma que, ante un error al especificarcorrectamente dicho convenio, termi-naríamos con una caída total del pro-grama.
Estos dos detalles son muy impor-tantes a la hora de envolver una DLL:en qué formato están las cadenas detexto y el convenio de llamada. Es algoque quien haya creado la citada DLLdebe indicarnos, o no seremos capa-ces de envolverla adecuadamente (otendremos que hacer complicadaspruebas).
Una vez realizada la importacióndel método nativo, creamos un méto-do estático en la DLL envolvente parahacer la llamada:
Podemos observar aquí cómo lla-mamos en primer lugar a ComplejoPolarpasándole un valor nulo al parámetrode cadena para que la función calcule eltamaño de la cadena, que asignamos asize. Y luego creamos un objeto del tipoStringBuilder y reservamos el tamañoadecuado, para que la siguiente llama-
da a ComplejoPolar nos almacene endicho objeto la cadena nativa.
Aquí la magia está en la clase String-Builder y la interoperabilidad median-te atributos. Lo destacable en nuestrocaso es que hemos forzado a que la cla-se tenga ya pre-asignado un tamañopara el búfer en el que se va a guardarla cadena. Lo demás corre por cuentadel motor de tiempo de ejecución de.NET Framework.
No obstante, conviene detenernosun momento en la asignación del
public static extern intComplejoPolar(NumeroComplejo c,
StringBuilder cadena);
public static string Complejo2Polar(NumeroComplejo c){
int size = ComplejoPolar(c,null);StringBuilder cadena = new StringBuilder(size * sizeof(char));ComplejoPolar(c,cadena);return cadena.ToString();
}
Convenio Explicación
StdCall El método llamado limpia la pila al finalizar. Es el convenioestándar y debe estar disponible para todos los compiladores decualquier lenguaje (.NET o no .NET)
FastCall Algunos parámetros se pasan en registros del procesador. Este con-venio no está soportado por .NET Framework. Si nuestra DLL usaesta forma, no podremos usarla directamente desde .NET y C#.
Cdecl El llamante limpia la pila. Es el convenio estándar de C.
ThisCall El primer parámetro es this, que se guarda en el registro ECX delprocesador, y los demás se colocan en la pila. Para importar clasesdentro de DLL compatibles (las de C++ no lo son).
Winapi No es un convenio de llamada propiamente dicho, pero se utilizacuando se van a llamar funciones de Win32 multiplataforma (esdecir, es el compilador de C# el que decide el convenio en base asi se está en Windows, Windows CE, etc.).
tamaño: ¿por qué size * sizeof(char)y no simplemente size? Bien, la fun-ción nativa devuelve el número decaracteres, pero también necesitamoscuántos bytes ocupa cada uno de esoscaracteres. En .NET, que utiliza Uni-code, cada carácter nos ocupará 2bytes. Si nuestro método nativodevolviera la cadena formateada enANSI, el motor de .NET se encar-garía de hacer la conversión a Uni-code. Como nuestra función escritaen C devuelve una cadena Unicode(una cadena del tipo wchar_t), .NETsabe qué hacer; pero en cualquier casotenemos que reservar correctamenteel espacio de memoria.
Observe el lector cómo hemos trans-formado la recepción de un puntero enlos parámetros de una llamada a funcióna un retorno de cadena en .NET.
El último paso consiste en hacer unallamada desde nuestra aplicación alensamblado envolvente:
Callbacks y delegadosOtro de los puntos calientes de la inte-roperabilidad son las funciones callback,cuya evolución natural en .NET son losdelegados. Windows utiliza las tambiénllamadas funciones de respuesta o deretro-llamada ampliamente; de hecho,la vida de cualquier aplicación (inclusoaquellas que son .NET puras), depen-de íntimamente de ello, ya que el bucleprincipal de mensajes no es otra cosaque un callback que es llamado por Win-dows cada vez que se produce un men-saje destinado a la citada aplicación.
En general los callbacks se utilizanen el mismo contexto que los delega-dos: una vez instalada nuestra función,Windows (en este caso el código denuestra DLL nativa) la ejecutará cadavez que sea necesario para informarnoso esperar alguna acción por parte dedicha función.
Existe una correspondencia directaentre los delegados y los callbacks nativos,de modo que en C# no es necesario indi-car nada especial. Sin embargo, siemprehay que tener en cuenta el convenio dellamada y el paso de argumentos.
Otro detalle muy importante tieneque ver con el recolector de basura de.NET, que nada quiere saber del mun-do nativo; por lo que si pasamos un dele-gado como callback y luego salimos deámbito o dejamos de usarlo, puede quesea eliminado y cuando el código nati-vo haga la llamada, intentará ejecutaralgo que ya no está ahí. El problema noserá que se nos lance una excepción; elproblema radicará en que habremosmachacado algo importante y nuestraaplicación debería terminar inmediata-mente. Para evitar esto allí donde pue-da producirse, una sentencia como lasiguiente nos evitará el problema:
En principio, mapear un delegadosobre un callback es tan trivial comodefinir el delegado con la firma ade-cuada. En nuestro caso, la función queactuará de retro-llamada para infor-marnos de que se ha calculado unnúmero complejo recibe una estructu-ra de número complejo como únicoparámetro:
Por tanto, nuestro delegado es tansencillo como:
Si nos fijamos, el desarrollador de C,sabiendo que su DLL iba a ser utilizadapor otros lenguajes de programación, seha preocupado de que el protocolo de lla-
mada sea __stdcall, por lo que no esnecesario hacer nada más. Sin embargo,en el callback que se ejecutará cuando seproduzca una condición de error no hasido tan cuidadoso, y ha dejado el proto-colo estándar de C, __cdecl, al omitirloen la declaración:
Aquí tenemos, pues, que indicar unatributo especial a la hora de definir enC# el delegado que hará la equivalencia:
Además, debido a ciertos problemasde compatibilidad hacia atrás con el tipológico en C y en Win32, también tene-mos que cambiar el atributo de retornopara que se mapee con el tipo correcto,ya que por defecto un bool en .NET serepresenta sobre 32 bits y en C, sobre 8.Si no indicáramos esto, el método recep-tor siempre recibiría true como valor deretorno.
Una vez que tenemos las firmas delos delegados que actuarán como call-backs, tan solo nos queda mapear losmétodos que van a envolver a la fun-ción nativa que va a instalarlos, así comoa la que nos va a calcular el inverso dedos números complejos utilizandodichos callbacks:
Esto es todo, en lo que respecta ala parte del ensamblado que envuelvea la DLL nativa. En el ejemplo de usocon C#, primero declaramos una claseque llamaremos Test y que implemen-ta dos juegos de delegados: uno estáti-co y otro de instancia. Si el lector quie-re ver cómo la DLL termina la ejecu-ción, tan sólo debe cambiar el valor deretorno en cualquier delegado de error.Finalmente, en Main primero hacemosuna llamada con los delegados estáti-cos y luego con los de instancia.
El listado 2 nos muestra el ejemplocompleto visto hasta aquí. Lo ideal esque el lector descargue el código fuentede la Web de la revista, ponga puntos deinterrupción y vea cómo actúa todo ensecuencia. Si quiere navegar dentro delcódigo nativo, no debe olvidar activar lacasilla “Enable unmanaged code debug-ging” en la pestaña “Debug” de las opcio-nes de los dos proyectos escritos en C#.
Y ahora, en C++/CLIVamos ahora a cambiar un poco elchip y ver lo mismo, pero desde el
public bool ComplejoError(NumeroComplejo c,ComplejoError e){
Console.WriteLine(“En ComplejoErrorStatic Error {0} en {1} {2}”,e.ToString(), c.Real, c.Imag);
return true;}
}
class Program{
static void Main(string[] args){
// Definimos un número complejo arbitrarioNumeroComplejo c;c.Real = 3;c.Imag = 3;
// Un número complejo que nos dará error al calcular su inversoNumeroComplejo cError;cError.Real = 0;cError.Imag = 0;
// Pasamos un número complejo en forma paramétrica a forma polarstring polar = Complejo.Complejo2Polar(c);Console.WriteLine(polar);
// Mostramos aquí cómo asignar un delegado estáticoComplejo.ComplejoErrorDelegate errorDlg = Test.ComplejoErrorStatic;// GC.KeepA live(errorDlg); // Esto no suele ser necesario.
// A quí hacemos la llamada para instalar los delegados // procedentes de métodos estáticos. // El primer parámetro se pasa directamente, y dejamos a C# // y a .NET que hagan todo el trabajo.// El segundo adopta una forma más convencionalComplejo.ComplejoInstalaCallbacks(Test.ComplejoCalculadoStatic, errorDlg);
punto de vista de C++/CLI como len-guaje destinado a la interoperabilidadentre código nativo y manejado. Elproyecto que prueba el nuevo ensam-blado mixto realizado en C++/CLI sellama UseDLL_CPP y, pese a su nombre,es exactamente el mismo código fuen-te que el anterior, UseDLL_CS. Única-mente hemos cambiado el nombrepara que sean diferentes, ya que aho-ra estamos enlazando con el ensam-blado WrapDLL_CPP en lugar deWrapDLL_CS.
Lo que sí es completamente dife-rente es el código dentro de WrapDLL_CPP,que está escrito en código mixto
C++/CLI y C++. Como concesión allector (y al propio Visual Studio),hemos construido todo el código fuen-te dentro del fichero de cabecera en ladeclaración de la clase, en lugar de par-tir la declaración en dos, las declara-ciones por un lado (en el .h) y el códi-go por el otro (en el .cpp), lo que seríalo más lógico dentro del paradigma deC/C++.
El primer detalle a resaltar es la for-ma de declarar la estructura NumeroCom-plejo mediante la palabra reservadadoble value struct. Con esto estamosdiciéndole al compilador que nuestraestructura es una estructura normal de
.NET4. Por lo demás, todo queda igual,ya que necesitamos ser compatibles conC#. Si no fuera así, podríamos utilizarla estructura nativa sin problema algu-no dentro del código .NET escrito enC++/CLI. La enumeración tampocotiene secreto alguno.
Luego declaramos una ref class (queen general es 100% equivalente a una cla-se .NET normal) que va a tener todos susmiembros estáticos para ser, de nuevo,compatibles con la versión anterior delensamblado y también para simular queestamos llamando a métodos “estáticos”dentro de una DLL nativa.
En primer lugar, veamos el con-vertidor a notación polar. En aparien-cia, el método es algo más complejo queel del envoltorio de C#, ya queC++/CLI no convierte directamenteestructuras manejadas en estructurasnativas (al revés sí), por lo que tenemosque realizar una asignación manual(también podríamos haber utilizadoInterop por atributos, pero queremosmostrar aquí otras cosas):
Si en lugar de pasar la estructura porvalor lo hubiéramos hecho por puntero(o referencia, algo que C++ tambiénadmite), podríamos haber obtenido unpuntero nativo a un elemento maneja-do pasado por referencia mediante elmétodo Marshall::ToPointer. O tambiénpodríamos haber bloqueado el punteromanejado mediante pin_ptr y haberpasado la dirección de ese puntero blo-queado al método. Otra forma seríamezclando ambos conceptos: obtenerun puntero a la estructura pasada, blo-quearlo y luego de-referenciar dichopuntero en el método nativo5.
// Hacemos la llamada para calcular el inverso de dos números// complejos. El segundo disparará el delegado de error.Complejo.ComplejoInverso(c, cError);
// Creamos un objeto de la clase Test para obtener // métodos no estáticosTest miTest = new Test();
// A signamos el método no estático de error.errorDlg = miTest.ComplejoError;
// A quí hacemos la llamada a instalar los delegados // procedentes de métodos “normales” (no estáticos). // El primer parámetro se pasa directamente y dejamos a C# // y a .NET que hagan todo el trabajo.// El segundo adopta una forma más convencionalComplejo.ComplejoInstalaCallbacks(miTest.ComplejoCalculado, errorDlg);
// Hacemos la llamada para calcular el inverso de dos números// complejos. El segundo disparará el delegado de error.Complejo.ComplejoInverso(c, cError);
}}
Listado 2. El ejemplo completo.
3 En oposición a ref struct, que correspondería a una estructura que iría por defecto alojada en la pila, saliéndonos del estándar. Si tenemos encuenta que en .NET una estructura es un tipo completo con semántica de pila y que una clase tiene semántica de montículo, en C++/CLI, podemosdiferenciar entre semántica de pila o montículo y estructura o clase. Es decir, si declaramos una value class, a efectos de .NET estaremos declarandouna estructura con sus miembros privados por defecto, mientras que si declaramos una ref class, lo que hacemos es declarar una clase normal(completamente equivalente a una clase de C#). Sin embargo, si declaramos una value struct, estaremos declarando la típica estructura de C#, a lavez que si utilizamos ref struct estaríamos haciéndonos con una clase de C# cuyos métodos por defecto son todos públicos.5 Ciertamente, en C++/CLI las posibilidades para pasar del mundo manejado al nativo y viceversa son prácticamente infinitas.
Una vez que hemos obtenido eltamaño que vamos a necesitar (no semuestra en las líneas de arriba), asig-namos memoria nativa (recordando queestamos dentro de un método maneja-do), volvemos a llamar al método nati-vo como si estuviéramos en C++ enlugar de en C++/CLI, y con el punte-ro obtenido creamos una variable detipo String y la inicializamos a través deun puntero nativo (que copiará el búfernativo a uno manejado). Luego libera-mos la memoria nativa y finalizamos.
Con este ejemplo, estamos viendocómo es posible mezclar de forma indis-tinta código manejado y nativo casicomo si no existiera diferencia entre.NET y C++. No obstante, en C# tam-bién podemos realizar casi la mismaconstrucción, pero ello nos forzaría aque todo nuestro código estuviera mar-cado como no seguro y no verificable.
Los delegados en C++/CLI sedeclaran de la misma forma que en C#,pero con la sintaxis del lenguaje. Obser-ve cómo indicamos al compilador queel delegado que se disparará en caso deerror usa el protocolo de llamada de Cen lugar del estándar (exactamenteigual que con C#. No se ha menciona-do antes, pero con C++/CLI podemosmezclar ambas formas de interopera-ción: la IJW propia del lenguaje y la deatributos estándar de .NET):
La función que instala las funcio-nes de callback es bastante más com-
pleja que en C#. Aunque podríamoshaber utilizado la forma de C#, nosinteresa aquí hacerlo de esta otramanera para poder explicar lo quesigue. El cuerpo del método está reco-gido en el listado 3.
La parte comentada del mismo tie-ne su explicación. Fijar los delegados real-mente no es necesario, ya que lo únicode lo que debemos asegurarnos es que elrecolector no los libere de forma acci-dental. Una forma es pinnear el delega-do, como se muestra en la parte comen-tada, algo que en este caso concreto nosería útil ya que, al estar en un métodoestático, el bloqueo se liberará al termi-nar la función. Ese bloque de códigovendría bien si nuestra clase fuera unaclase normal y dichas líneas estuvierandentro de un método de inicialización,por lo que el bloqueo permaneceríadurante toda la vida de dicho objeto. Aquíse pone simplemente como muestra.
La siguiente línea sí que es necesa-ria, ya que asigna a un puntero nativollamado pCalculado la dirección del dele-gado. El moldeo a fncComplejoCalcula-do es obligatorio, ya que la llamada almétodo ToPointer de IntPtr devuelve
un puntero a void. Es uno de los casosen que C++ necesita asegurarse de quesabemos qué estamos haciendo. Quizásel lector piense que, ya que el métodoGetFunctionPointerForDelegate tambiénestá presente desde C#, esta construc-ción podría haberse hecho desde dicholenguaje; pero esto no es del todo cier-to, ya que desde C# no podemos obte-ner directamente un puntero a funciónnativa. Para hacerlo, sería necesario uti-lizar un método adaptador… escrito enC++/CLI (que, al final, es lo que esta-mos haciendo).
La forma para el delegado de errores idéntica, pero se realiza en dos pasosen lugar de uno.
TCHA R *pBuffer = new TCHA R[size];::ComplejoPolar(cc, pBuffer);String ^returnVal = gcnewString(pBuffer);
delete[] pBuffer;
/** Esta función instala los callbacks que se ejecutarán cuando se esté* calculando el inverso de un número complejo*/static void ComplejoInstalaCallbacks(
{// No es necesario “pinnear” el delegado, pero podría ser útil // en alguna circunstancia.// pin_ptr<ComplejoCalculadoDelegate ^>pinCalculado=&callbackCalculado;// pin_ptr<ComplejoErrorDelegate ^>pinError=&callbackError;
// Esta forma obtiene el puntero a la función directamentefncComplejoCalculado pCalculado = (fncComplejoCalculado)
// Esta otra lo hace mediante un paso intermedio. A mbas son // completamente equivalentesIntPtr pError=Marshal::GetFunctionPointerForDelegate(callbackError);
// Hacemos la llamada a la función nativa de la DLL::ComplejoInstalaCallbacks(pCalculado,
Es cierto que esta forma es bas-tante más compleja e indirecta que através del Interop de atributos de C#,pero lo interesante de este modo derealizar las cosas es justamente el con-trario: llamar a un método callbacknativo desde código manejado. Odicho de otra forma: poder ejecutarcódigo relativamente arbitrario den-tro de .NET, incluso código ensam-blador, tal y como aparece en la pági-na 177 del libro de Nishant Sivaku-mar [1]. El truco está en llamar a lafunción inversa de GetFunctionPoin-terForDelegate, GetDelegateForFunc-tionPointer, que devuelve un delega-do de .NET a partir de un puntero auna función nativa:
Con el método de arriba estamosobteniendo un delegado que es un pun-tero al método nativo ComplejoInversoy luego llamando a dicho delegado. Elejemplo completo está en el códigosuministrado.
Ya sólo nos queda comentar elmétodo ComplejoInverso de nuestraDLL, y como en este caso tenemos quehacer dos conversiones de estructurasmanuales, lo dejamos igual al de C#; esdecir, usamos el clásico Interop por atri-
butos, ya que nada nos impide usarlotambién en C++/CLI.
Más sobre InteropPosiblemente el Interop más común yquizás también más complicado para eldesarrollador no acostumbrado a él seala conversión entre las cadenas .NETy las típicas terminadas en nulo de C.Más arriba hemos visto cómo conver-tir un puntero a cadena de C a unacadena de .NET a través de un String-Builder. También lo hemos hecho conC++/CLI aprovechando su propio sis-tema de interoperación. No obstante,todavía queda una forma de hacerlodirectamente desde C# que puede
resultar bastante útil, aunque quizás seala más lenta de todas.
La clase Marshal del espacio de nom-bres System.Runtime.InteropServicesofre-ce una gran cantidad de métodos parainteroperar entre código nativo y mane-jado. Con ella se puede realizar casi cual-quier tipo de conversión; si bien no de for-ma automática, sí de forma manual. Porejemplo, los métodos ReadInt32 y Wri-teInt32 permiten extraer y escribir unentero de 32 bits de un búfer nativo acce-
dido mediante un IntPtr. Otro ejemplo:si necesitamos reservar memoria nativapara pasarla a un método nativo, pode-mos utilizar el método A llocHGlobal, quenos devolverá, de nuevo, un IntPtr capazde ser pasado como puntero de C lla-mando al método ToPointer del mismo.
Volviendo al tema de las cadenas, conlos métodos PtrToStringA nsi y PtrToS-tringUni podemos obtener una cadena.NET a partir de un IntPtr que apuntea una cadena nativa terminada en cero.También tenemos las funciones inver-sas, StringToHGlobalA nsi y StringToH-GlobalUni, que toman una cadena .NETy devuelven un IntPtr que puede serpasado a una función nativa como pun-tero a cadena terminado en cero. En esteúltimo caso, no debemos olvidarnos deliberar la memoria asignada al llamar adichos métodos con FreeHGlobal, pasan-do el puntero obtenido con las funcio-nes anteriores una vez que dichas cade-nas nativas no sean necesarias.
Tampoco podían faltar métodospara trabajar con componentes COMnativos, de los que se cuenta con unabuena cantidad, tanto para asignarmemoria y recursos para el componentecomo para comunicarse con él.
El único inconveniente de todasestas funciones es el rendimiento. Sinuestra aplicación manejada las usa conprofusión, deberíamos estructurarla deforma que se minimice su utilización ylos saltos entre código manejado y nati-vo. Y si eso no pudiera ser así, quizásuna opción perfectamente válida seríahacer la parte de la aplicación que acce-da al mundo nativo en C++/CLI, apro-vechando el modo mixto que este len-guaje ofrece, tal y como se ha dejadoentrever en este artículo.
Sivakumar, Nishant. “C++/CLI in Action”. Manning Publications, 2007.
Sutter, H. “A Design Rationale for C++/CLI”, en http://www.gotw.ca/publications/C++CLIRationale.pdf. Traducciónal castellano, por Ontivero, R. y Hernández O., en http://rfog.cmact.com/a_design_rationale_es.zip.
Núñez, H. “Implementando wrappers en C++/CLI. Reproducción de sonido en .NET”. En dotNetManía nº 55,enero de 2009.
Como la vida mismaUsted conoce los riesgos que tiene que su sistemano funcione lo más eficientemente posible –¡quiénno lo ha sufrido alguna vez!–, y una de sus laborescomo administrador de bases de datos, entre otrasmuchas, debería ser conocer la capacidad de su sis-tema, y en la medida de lo posible anticiparse a situa-ciones inesperadas. Además, si de alguna forma esusted capaz de almacenar en “algún sitio” la activi-dad de sus instancias de SQL Server, esta informa-ción también podrá servirle a posteriori como herra-mienta de diagnóstico. Usted conoce bien la serie-dad con que hay que tratar estas cosas, porque alfinal es dinero que le cuesta a su empresa; si su sis-tema gestiona 15.000 operaciones de negocio en undía, y si dicha capacidad se reduce en tan solo un 3%,simplificando mucho la problemática, la teoría diríaque el sistema estaría dejando de gestionar 450 ope-raciones en todo el día. ¿Es eso mucho? ¿Es asumi-ble? ¿Qué supone para su empresa? ¿Qué pasa conla sensación del usuario? ¿Y la imagen de la empre-sa? Imagine que su empresa está presente en la Weby gestiona apuestas, reservas de vuelos, tren, hote-les, o incluso venta de productos de software; ima-gine que su empresa es un broker de transaccionesbancarias… Al final, su sistema de bases de datos escrítico en el día a día de la empresa entre muchasvariables, y su postura debe ser la de por lo menosgarantizar que las variables que de usted dependenestén lo más sanas posible.
Qué tipo de información nos gustaría“recolectar”En definitiva, la capacidad transaccional de su siste-ma irá de la mano de la capacidad que tenga su ser-vidor de bases de datos para resolver/procesar peti-ciones de consultas T-SQL; esta información se pue-de obtener del contador “Batch Requests/sec” delobjeto “MSSQL$<nombre_instancia>:SQL Statis-tics” del Monitor de rendimiento (System Monitor).Además, sería importante capturar contadores de laactividad física del sistema de almacenamiento(“Bytes/sec”, “Disk Reads/sec” y “Disk Writes/sec”);en este ejemplo vamos a monitorizar la cantidad deoperaciones realizadas contra el sistema de almace-namiento y la cantidad de bytes transferidos (tantoleídos como escritos). Por otra parte, me gustaríarecomendarle que incluyera contadores personaliza-dos de rendimiento en vuestras capas intermedias:como introducción al concepto, diría que usted pue-de programar sus aplicaciones para que expongan“hacia fuera” –que podrá consultar con el Monitorde rendimiento– las veces que la ejecución de su com-ponente pasa por áreas concretas de su código… Paramás información, consulte la referencia [2].
Definición del colector de datos perso-nalizadoAsumimos que el mes pasado se han puesto en mar-cha los colectores estándar de Performance Studio.
SQL Server Performance StudioCreación de colectores de datos personalizados
SQL Server
En nuestra entrega anterior[1], hicimos una introducción a las nuevas capa-cidades de SQL Server 2008 para monitorizar instancias de SQL Server; enel artículo de este mes, vamos a salirnos un pelín del “estándar” que ofre-ce la interfaz gráfica para adaptar el producto a nuestras necesidades con-cretas. Antes de seguir adelante, recomendaría familiarizarse con los con-ceptos tratados en el artículo del mes pasado.
Eladio Rincón
Eladio Rincón es MCT yMVP en SQL Server. Ela-
dio es Director de Tecno-logías de Bases de Datos
para Solid Quality enEspaña y Portugal, y man-
tiene con sus compañerosde departamento El
Rincón del DBA(http://blogs.solidq.com/ES/ElRinconDelDBA ), don-
de comparten sus expe-riencias en escalabilidad,
seguridad, rendimiento ydiseño eficiente de siste-mas de bases de datos.Puedes contactar con
Recuerde que hay tres grandes grupos,“Disk Usage”, “Query Statistics” y “Ser-ver Statistics”; en nuestro caso, los conta-dores que acabamos de comentar los aña-diremos al grupo “Server Statistics” (tiposde colectores relacionado con el Monitorde rendimiento). En primer lugar, com-probaremos que el proceso de captura dedatos está en funcionamiento con lasiguiente consulta:
use msdbgoselect *from [msdb].[dbo].
[syscollector_config_store]
Donde la columna CollectorEnabledcon un valor de 1 indicará que está habi-litado (figura 1).
Para habilitar/deshabilitar los traba-jos desde TSQL, usaremos las siguien-tes sentencias:
use msdbgo— habilitar colectores de datosexec [msdb].dbo.sp_syscollector_
enable_collector— deshabilitar collectores de datosexec [msdb].dbo.sp_syscollector_
disable_collector
Una vez que hemos comprobado elestado, nos tocará definir el colector per-sonalizado que queremos crear; el pro-ceso de creación constará de las siguien-tes tres fases:
1. Crear el objeto contenedor de la infor-mación, al que llamaremos “DataCollector DNM”.
2. Añadiremos a ese objeto la informa-ción que queremos capturar; ennuestro caso:
• Actividad de servidor de SQL Ser-ver (contadores de rendimiento).
• Traza de SQL Profiler.
3. Para finalizar, habilitaremos elcolector.
1. Crear el colector de datos
Para crear el colector de datos, usaremosel procedimiento almacenado sp_sysco-llector_create_collection_setde la basede datos msdb; en nuestro caso, usaremoslas sentencias T-SQL que se presentanen el listado 1, que nos devolverán comoresultado el identificador del colectorrecién creado –guárdelo, porque lo nece-sitará en los siguientes pasos (en mi caso,el ID obtenido fue 6)–.
Como información relevante delprocedimiento almacenado tendremos:
• @name: nombre del colector de datos• @collection_mode: si se desea que la
carga sea cacheada o se haga directa-mente en base de datos.
• @days_until_expiration: caducidad delos datos capturados.
• @schedume_name: frecuencia con que lainformación se sube a la base de datosde repositorio.
Tras crear el colector, podrá com-probar desde SQL Server ManagementStudio que éste se ha añadido a la lista de
colectores dentro del desplegable “<Ins-tancia SQL Server>” | “Management”| “Data Collection”, como se puede veren la figura 2.
2. Añadir al colector lainformación que deseamos capturar
Para añadir al colector la informacióna capturar, usaremos el procedimien-to almacenado sp_syscollector_crea-te_collection_item de la base de datosmsdb; además, como hemos decididocapturar información de actividad deservidor del Monitor de rendimiento,necesitamos conocer el UID de este tipode colectores con la siguiente consulta:
use msdbgo
Figura 1
Figura 2
use msdbgodeclare @id intdeclare @uid uniqueidentifierEXEC [dbo].[sp_syscollector_create_collection_set]
@name=N’Data Collector DNM’,@collection_mode=0, — modo cacheado@description=N’Captura de actividad física de discos’,@days_until_expiration=5, — 5 días de histórico@schedule_name=N’CollectorSchedule_Every_5min’,@collection_set_id=@id OUTPUT,@collection_set_uid=@uid OUTPUT
Select *From[dbo].[syscollector_collector_types] where name = N’Performance Counters
Collector Type’
En mi caso, la columna collec-tor_type_uid tiene el valor 294605DD-21DE-40B2-B20F-F3E170EA1EC3; además,recuerde que necesitará el identifica-dor del colector obtenido anterior-mente.
Para finalizar, necesitamos definir quécontadores queremos capturar; esto seindicará mediante etiquetas XML quedeberán ajustarse al esquema del listado2 –cada tipo de colector de datos se ajus-ta a su propio esquema–.
En nuestro caso, el XML será el quese muestra en el listado 3, quedando lasentencia T-SQL a ejecutar como en ellistado 4 (observe que hemos indicado,mediante el argumento @frequency, quela frecuencia de captura será de 15segundos).
Si volvemos ahora a SQL ServerManagement Studio, y comprobamos laspropiedades del colector, veremos lo quese muestra en la figura 3.
3. Habilitar la captura de datos por elcolector
Para finalizar, habilitaremos el colectorpara que empiece a capturar datosmediante la siguiente sentencia T-SQL:
use msdbgoexec sp_syscollector_start_collection_set
@collection_set_id = 6
Leyendo la información capturada
Tras poner en marcha la captura, lle-ga la hora de consultar la informaciónrecogida. Como comentamos en el artí-culo del mes pasado, la información sealmacena en una base de datos (datawa-rehouse) que se configura al inicio del pro-ceso; como se puede –y es habitual–alma-cenar información de diferentes sesionesen la base de datos, Microsoft ha diseña-do las tablas según el esquema de la figu-ra 4, donde las tablas representan lassiguientes relaciones:
• snapshots.performance_counter_values:cada contador de rendimiento monito-rizado.
• core.source_info_internal: cada unode los colectores de usuario y sistema.
• core.snapshots_internal: cada “subida” de cadacolector.
• snapshots.performance_counter_instances: elvalor de cada contador de rendimiento para cada“subida”.
Tras familiarizarnos con las tablas relacionadas, nosquedaría consultar la información almacenada en ellas;para ello hay multitud de posibles soluciones, y soloenumeraré unas cuantas:
• Conjuntos de procedimientos almacenados que pue-de crear para sus necesidades concretas.
• Conjunto de sentencias T-SQL creadas “ad-hoc” paracada ocasión.
• Conjunto de informes creados con SQL ServerReporting Services.
• Documento Excel vinculando las tablas anteriores.
En mi opinión personal, la opción que consideromás flexible y atractiva para el trabajo que solemos haceres vincular las tablas snapshots.performance_coun-ter_values y core.source_info_internal desde Excely crear gráficos impactantes para mostrar nuestras con-clusiones de forma gráfica; como ejemplo, en la figura5 se presenta un gráfico obtenido desde Excel para unaspruebas de rendimiento que tuvimos que hacer hacerelativamente poco tiempo.
ConclusionesComplementando el artículo del mes pasado, hemos vis-to un ejemplo práctico de cómo crear y capturar infor-mación de monitorización mediante colectores de datospersonalizados; como se habrá dado cuenta, más allá deSQL Server Management Studio se puede llegar a unnivel de personalización extraordinario para dar soportea las necesidades concretas de nuestras instalaciones. Comoejercicio posterior, quedaría consolidar en un únicoalmacén de datos información de monitorización prove-niente de distintos servidores… ¡Happy monitoring!
Figura 3
Figura 4
Figura 5
Referencias
Rincón, E. SQL Server Performance Studio. Nueva herramienta de monitorización en SQL Server 2008. EndotNetManía nº 56, febrero de 2009, págs. 38-40.
Jones, D. E. “Using custom attributes to add performance counters to your application”, enhttp://www.codeproject.com/KB/vb/PerformanceCounterUtils.aspx.
El primer paso, por supuesto, y para los que no lasconozcáis, es explicar qué es esto de las 12 pre-guntas de Joel Spolsky, que podéis encontrar aquí:http://tinyurl.com/12spolsky. Resumiendo, se tra-ta de 12 preguntas que deberíamos hacernos paraevaluar nuestro entorno de trabajo, ver nuestrospuntos débiles y empezar a trabajar para solucio-narlos. Las preguntas van desde el plano técnicohasta el plano más de gestión y de equipo.
Las preguntas son:1. ¿Usas control de código fuente?2. ¿Puedes construir el producto en un único
paso?3. ¿Haces compilaciones completas diarias?4. ¿Tienes una base de datos con los defectos
(bugs)?5. ¿Arreglas los defectos antes de escribir códi-
go nuevo?6. ¿Tienes una planificación actualizada?7. ¿Tienes especificaciones?8. ¿Tienen los desarrolladores condiciones
tranquilas de entorno?9. ¿Usas las mejores herramientas que puedes
comprar?10. ¿Dispones de testers?11. ¿Haces escribir código en las entrevistas?12. ¿Realizas pruebas de usabilidad de “pasillo”?
Ahora es el momento de evaluaros, y ver quépuntuación sacáis… ¿Ya está? Bueno, no os asustéiscon los resultados, vamos a ver cómo Visual StudioTeam System nos puede ayudar a dar respuesta aalgunas de estas preguntas y mejorar nuestro entor-no. Por supuesto, Team System no va a dar respuestaa todas las preguntas, y mucho menos por sí solo;debemos ser nosotros los que saquemos el mayorpartido de esta herramienta. Vamos a por ello.
Antes de continuar, una pequeña aclaración: eneste artículo no se pretende profundizar en ningu-no de estos temas; lo que pretendo es daros una guíade cuál puede ser un buen punto de partida de undespliegue de Team System, y un posible orden deimplementación de las distintas prácticas y de lasherramientas, valiéndome de los puntos propuestospor Joel Spolsky, si bien no todos ellos se pueden res-ponder con Team System. Concretamente, nos cen-traremos en los puntos 1, 2, 3, 4, 6, 7 y 10.
¿Usas control de código fuente?Esto parece básico, pero a veces nos olvidamos delas cosas más básicas y no las sabemos aprovecharo no nos acordamos de que están ahí. Sin embar-go, es algo de lo que podemos sacar partido inme-
Las 12 preguntas deSpolsky y Team System
ALManía
Luis Fraile es MVP de Team Sys-
tem y colabora activa-mente en MAD.NUG(grupo de usuarios de
.NET de Madrid).Actualmente es direc-
tor técnico en Multido-mo Networks, dondedesarrollan un produc-to de software para lagestión de dispositivosdomóticos y cámaras
de vigilancia a través deInternet mediante inter-
faces Web, teléfonosmóviles, Media Center,etc. Puede consultar sublog en www.lfraile.net.
Una de las primeras preguntas que se hacen al empezar a implantarTeam System es ¿y por dónde empiezo? ¿qué hago? Son tantas las prác-ticas, herramientas, decisiones, que se hace difícil arrancar. Sin embar-go, Joel Spolsky propuso hace tiempo 12 sencillas preguntas para eva-luar nuestra situación. Pues bien, vamos a darle una vuelta a esas pre-guntas, para usarlas como punto de comienzo.
diatamente, y algoimprescindible antes deplantearnos cualquierotra acción.
El objetivo del controlde código fuente es el depermitirnos, de un modosencillo, integrar el códi-go de los desarrolladoresque hay en el proyecto.En relación con esto, losproblemas suelen venir ala hora de modificar unmismo proyecto o fiche-ro por varios desarrolla-dores a la vez, algo que enla práctica totalidad deproyectos es inevitable.Además, el control decódigo fuente nos va apermitir tener un histórico de todas las modificacionesde los ficheros del proyecto y de quienes las hicieron.
Aquí Team Foundation Server nos proporciona laherramienta Version Control (figura 1), que nos faci-lita, mediante las acciones básicas de desproteger unfichero para editarlo, protegerlo cuando hayamos ter-minado de editarlo para que esté a disposición del res-to del equipo y crear shelves de conjuntos de cambios, lalabor de compartir el código.
Version Control también nos permite gestionar elciclo de vida del código a lo largo de las versiones de unproducto, aunque éste es un proceso bastante comple-jo y yo os recomendaría dejarlo para cuando ya estemosmuy acostumbrados al trabajo con el control de versio-nes y hayamos comprendido su flujo de trabajo.
Esta funcionalidad es la de los branches, que nospermiten crear ramas paralelas con una “copia” denuestro código, sobre la que trabajar en paralelo,para posteriormente unirlas a la principal. Esto esexplicándolo muy básicamente, ya que este procesotiene muchas implicaciones de esto, y hay que tenermucho cuidado con cómo se realiza la gestión deestas ramas. En este sentido, la mejor fuente de infor-mación es la documentación que podemos ver en
http://www.codeplex.com/TFSBranchingGuideII, quecontiene ejemplos, guías y recomendaciones a la horade gestionar nuestro repositorio de código, y parti-cularmente la gestión de branches con Team Foun-dation Server.
¿Puedes construir el producto en un único paso? ¿Haces compilacionescompletas diarias?
Bien, una vez que el equipo lleve un tiempo traba-jando con el control de código fuente (no hace faltallegar a los branches), lo siguiente que nos plantea-mos es cómo construimos nuestro producto.
En proyectos sencillos, será tan simple como esco-ger la configuración de Release y compilar la solución;pero la vida no siempre es sencilla, y la mayor parte delas veces tendremos varias soluciones, librerías que pro-vienen de otros equipos, proyectos de instalación, etc.que muchas veces nos hará de la construcción un auten-tico calvario a la hora de ponerlo todo en orden.
La primera premisa básica es poder obtener la últi-ma versión del código fuente para compilar de un úni-co punto, pero esto ya lo tenemos con el apartadoanterior ¿verdad? Ahora viene el siguiente paso: com-pilar todo junto y en un solo paso. Para esto nos vamosa apoyar en Team Build. De Team Build y de la inte-gración continua hemos hablado en el número 50 dedotNetManía.
El primer paso es configurar la compilación delproyecto mediante Team Build, lo que se hace siguien-do los pasos de un sencillo asistente (figura 2), quenos permite seleccionar la configuración, proyectos,soluciones y pruebas a ejecutar (¡recordad que nin-guna compilación está completa si no se ejecutan las
Figura 1
Para más información acerca del uso de VersionControl, os recomiendo este enlace: http://tin-yurl.com/TFSVC, donde están los tutoriales de Micro-soft acerca del uso de Version Control, además defuturos artículos en esta revista.[ ]
pruebas!). La potencia de Team Build reside en esta“sencillez” de configuración, y sobre todo en la capa-cidad de extenderla a posteriori con nuestros pro-pios pasos de compilación, algo que vimos en elnúmero 55 de esta misma revista.
Una vez que ya tenemos una compilación que cons-truye nuestro producto en un único paso, lo siguientees ejecutarla al menos una vez al día, para prevenir loserrores de integración que surgen en los equipos. Paraesto, Team Build nos permite especificar durante la eje-cución del asistente tanto un calendario de ejecuciónperiódica de la compilación, como opciones más auto-matizadas aún, como la integración continua, que eje-cuta la compilación cada vez que alguien sube códigofuente nuevo al repositorio de código.
Como podéis ver, todo va muy unido: reposito-rio de código, compilaciones, etc. De ahí que pri-mero se empiece con el control de código fuente,que es la base de todo.
¿Tienes una base de datos con los defec-tos (bugs)? ¿Tienes especificaciones?Volvemos a unir dos puntos, y aquí me salto un pocoel orden de las preguntas de Joel.
Si alguien nos pregunta cuántos bugs tenemos ennuestro proyecto, y de qué severidad, ¿sabríamos dar-le una respuesta concreta? Es muy importante que dis-pongamos de este tipo de información, como los bugso las especificaciones de lo que queremos construir, sibien la podemos llevar de muchos modos distintos,como por ejemplo en una simple hoja de cálculo Excel;el ideal es que con esta información podamos obtenermás datos acerca del estado del proyecto.
En Team Foundation Server, esto lo consegui-remos mediante los Work Items (figura 3). Los workitems (WI) son unidades de trabajo que nos sirvenpara representar tanto tareas como bugs, especifica-ciones, etc. Estos WI contendrán la informaciónnecesaria, dependiendo de lo que queramos almace-nar; si los campos previstos de antemano no son sufi-cientes, siempre podemos adjuntarle directamenteun documento, o un enlace a un documento exter-no, situado por ejemplo en un servidor de Share-Point. Esta información también dependerá de lametodología que estemos usando en el proyecto,
Figura 2
Figura 3
Para más información acerca de Team Build, podéisconsultar http://tinyurl.com/TeamBuildES, página deMSDN con información y tutoriales sobre TeamBuild, así como los números 50 y 55 de ddotNet-Manía, en los que se habla acerca de la integracióncontinua y de su extensibilidad con Team Build.[ ]
NOTA
La potencia de Team Build reside en esta "sencillez" de configuración,
y en la capacidad de extenderla con nuestros propios pasos
especificada a través de la plantilla de proyecto quehayamos escogido al crear el proyecto de Team Foun-dation Server.
La gran ventaja de gestionar con los WI todos loselementos de trabajo consiste en que después podremosexplotar gran parte de la potencia de los informes basa-dos en estos WI que ofrece Team Foundation Server.
Estos elementos de trabajo tienen además sus pro-pios flujos de trabajo, para que podamos comprobarlos estados por los que pasan, y en el caso de los bugssu severidad, para poder saber qué elementos tene-mos abiertos, de qué tipo, con qué prioridad, y en quéestado se encuentran, para poder responder la pre-gunta que nos hacíamos al principio.
Si esto lo unimos al control de código fuente,al que podemos también asociar estos elementos detrabajo durante las operaciones de actualizar el códi-go en el repositorio, y a las compilaciones de TeamBuild, que nos dan la información de los elemen-tos de trabajo que han sido modificados (mediantela asociación antes mencionada) en esta compila-ción, permitiéndonos saber qué conjunto de cam-bios se hicieron en qué compilación, podemos valo-rar la potencia de tener almacenadas nuestras tare-as como WI.
Realmente, este es un paso que podemos hacerincluso antes que el control de código fuente, perodebido a la importancia inicial del control de códi-go fuente, y a la posibilidad de unir estos elementosde trabajo al código, yo os recomiendo que antes quetrabajar con esto empecéis por el control de códigofuente.
¿Tienes una planificación actualizada?
Vale, lo admito, esto es algo que se debe hacer siem-pre y antes que cualquier cosa, incluido el control decódigo. Pero aquí estoy hablando de gestionar estomediante la implementación de Team System; por esova después de los WI.
¿Por qué? Pues porque los WI es de lo que nosvamos a valer para esto. Por ello, es muy importan-te que, llegados a este punto, el equipo tenga el tra-bajo con el control de código fuente y los WI muyasimilado.
Si bien se puede hacer por separado, lo ideal esacostumbrar a los desarrolladores a modificar los WIde sus tareas en el momento de hacer el check-in (subi-da del código) desde la propia interfaz que están acos-tumbrados a manejar: Visual Studio. Como podéisver en la figura 4, en la ventana de check-in tenemosuna opción “Work Items”, que nos permite, median-te una de las consultas de WI disponibles en el pro-yecto, seleccionar qué tareas están enlazadas a estecódigo. También podemos actualizar la planificación:si hacemos doble clic, se nos abrirá el WI que quere-mos editar, pudiendo rellenar en ese momento el tra-bajo completado y el trabajo que nos queda. De estemodo, los desarrolladores tienen el acceso, sin salirde su herramienta, para poder actuar sobre la plani-ficación y mantenerla actualizada.
Todo esto, junto a los informes de proyecto deTeam System y a la integración de éste con MicrosoftExcel y Project, nos da una visión del trabajo com-pletado, del que queda y de las desviaciones. Si estoos parece poco, apuntaros también que podéis exten-
Para más información, en este enlace de MSDN:http://tinyurl.com/WORKITEMS tenéis mucha infor-mación acerca de los elementos de trabajo, así comodiversos tutoriales para que exploréis sus capaci-dades. Además, os recomiendo estar atentos a ddot-NetManía, como siempre, donde hablaremos enalgún momento sobre este tema.[ ]
NOTA
Figura 4
Para más información sobre este tema, podéis consultar http://tinyurl.com/TFSReports.[ ]
der el sistema con vuestros propios informes deReporting Services, o incluso conectaros a la fuen-te de datos de informes desde Excel y sacar infor-mes ad hoc.
¿Dispones de testers?Más que testers, aquí me refiero a: aparte de tes-ters, ¿dispones de herramientas para testing?¿Haces pruebas? ¿Haces pruebas unitarias? Estoes muy importante; no nos cansaremos de repetirque la calidad no es opcional y debemos asegurar-nos de que los requerimientos se pueden probar,y necesitamos herramientas que nos faciliten estetrabajo.
Con Visual Studio Team System (desde VisualStudio Team System Developers Edition, con lasherramientas de pruebas unitarias, hasta Visual Stu-dio Team System Testers Edition, con sus herra-mientas de pruebas de carga, pruebas Web, etc.),disponemos de varias herramientas que nos van afacilitar esta tarea; pruebas que podremos auto-matizar para repetirlas de un modo sencillo siem-pre que podamos.
Realmente este es un camino que debemosemprender lo antes posible, pero hay que tener muyclaros los pasos anteriores, ya que todo en TeamSystem está conectado, y una vez que tengamos cla-ros procedimientos como los de Team Build, podre-mos agregar a nuestras compilaciones las pruebasautomatizadas; especialmente importantes en estepaso son las pruebas unitarias.
Además, todos los resultados de pruebas lospodremos incluir en el almacén de datos de TeamFoundation Server, integrándolos, cómo no, conlos informes, con lo que podremos obtener tam-bién informes acerca de la calidad del proyecto, yponerlos en correspondencia con bugs, planifica-ción, código, compilaciones, etc.
ConclusionesEs muy importante que a la hora de implementar éstasy otras, no comencéis con una práctica hasta que nohayáis cogido soltura suficiente con la anterior. El obje-tivo es que estas prácticas nos faciliten el trabajo, no quenos creen impedimentos; si nos los crean, acabaremosno usándolas y volviendo a un punto anterior, y con reti-cencias a utilizar nuevas prácticas.
Aunque aquí no lo hemos mencionado, también esmuy importante que tengamos una metodología quenos guíe a lo largo de todo este proceso, con buenasprácticas de gestión, de desarrollo y de organización delequipo; esto es la base de todo, y sin ello estaremos per-didos. Además, es importante que se trate de una meto-dología ya conocida, de la que tengamos suficientes refe-rencias y que adoptemos sin fisuras.
Por último, y para acabar, la pregunta 9: ¿Usas lasmejores herramientas que puedes comprar? Bueno, yocreo que para esta pregunta es obvia la respuesta que osvoy a dar, y aunque es cierto que no existen balas de pla-ta tampoco en el área de las herramientas, si seguimosun procedimiento ordenado en su implementación,estando además apoyados por gente que ya lo haya hechoantes y comparta su experiencia con nosotros, VisualStudio Team System es una herramienta que perfecta-mente puede dar respuesta a esta pregunta.
dotN
etM
anía
<<
52
dnm.ALManía<<
Ejemplos e instrucciones para el uso de las herra-mientas de testing las podéis encontrar en MSDNaquí: http://tinyurl.com/VSTSTesting. Además, os reco-miendo el blog de JJames Whitaker (en inglés):http://tinyurl.com/JWTest, en el que, aunque no sehabla de testing con Team System, podéis leer inte-resantes artículos acerca del testing funcional y obte-ner grandes ideas para vuestros proyectos.[ ]
NOTA
Es muy importante que a la hora de implementar éstas y otras, no comencéis con una práctica hasta que no hayáis cogido soltura
Me gusta tu planteamiento. Y me gustaría utilizarloen mis clases para explicar las diferencias entreAJAX y Silverlight. Una aplicación Silverlight esuna aplicación Web, pero con un modelo de pro-gramación y una interfaz de usuario que tienenmucho más en común con las aplicaciones de escri-torio. Dicho esto, hay que añadir que el runtime deSilverlight es radicalmente diferente de un entor-no de escritorio, que opera bajo confianza total (fulltrust). Este es un punto importante a recordar.
De vuelta al problema, ¿por qué no puede uti-lizarse wsHttpBinding para llamar a un servicioWCF desde Silverlight? La respuesta simple esque es así por diseño. Pero vamos a analizarlo conalgo más de profundidad.
Un servicio WCF que habilita clientes Sil-verlight está forzado a utilizar el esquemabasicHttpBinding, lo que significa que debe exis-tir un endpoint configurado para peticiones SOAP1.1 en el servicio. El contenido del fichero Web.con-fig de la aplicación ASP.NET debe incluir losiguiente:
Como puede verse en la figura 1, el esquemabasicHttpBinding no ofrece al cliente Silverlightlas mismas opciones de seguridad que tendría uncliente con confianza total. Las opciones de segu-ridad para los servicios WCF se limitan a HTTPSy asumen “ninguna seguridad” por defecto.
¿Debería sorprendernos este modelo de segu-ridad tan simple para escenarios AJAX y Silver-light? Bueno, ambos son clientes Web con uninterés principal en los servicios: hacer peticiones
WCF y Silverlight juntos
Dino Esposito
Arquitecto en IDesign,Dino Esposito es una de
las autoridades mundialesreconocidas en tecnologías
Web y arquitectura desoftware. Sus libros másrecientes son "Program-ming ASP.NET 3.5-Core
Reference" e "IntroducingMicrosoft ASP.NET AJAX"
(Microsoft Press). Esponente regular en even-
tos de la industria deámbito mundial, como
TechEd o DevConnec-tions, y europeos, como
DevWeek y Basta.
Silverlight 2 es la variante de escritorio de la Web, ¿no es así? Ahora bien, ¿por qué razónno soporta wsHttpBinding? ¿Hay alguna razón no evidente por la que los chicos de Micro-soft se hayan basado en SOAP para las comunicaciones Web y WCF?
todonet@qa
Este mes exploramos aspectos internos de los enlaces (bindings) de WCF y cómo serelacionan con Silverlight. En particular, veremos las razones por las que en Silverlightno hay wsHttpBinding y solo se soporta el esquema más simple de basicHttpBinding.También hablaremos sobre el modo de compatibilidad WCF/ASP.NET y la instalaciónde Silverlight en empresas de gran tamaño.
El modo de compatibilidad de WCFhace posible el funcionamiento de losclientes AJAX, y como puede imaginarsupone cierta limitación para el servi-cio WCF en sí mismo. No se necesitala compatibilidad para servicios que noserán llamados por clientes AJAX. Lanecesidad del modo de compatibilidadse deriva de la necesidad de compartirel mismo entorno de ejecución entre laspáginas ASP.NET y los servicios WCF.Cuando un servicio WCF es alojado porIIS, “vive” dentro de una aplicaciónASP.NET. Si esa aplicación tiene una o
más páginas AJAX que necesitan llamaral servicio vía script, el modo de com-patibilidad se convierte en una necesi-dad. Aunque no en todos los casos.
Por defecto, los servicios WCF alo-jados en IIS comparten con las páginasASP.NET un dominio de aplicacióncomún y único. Por tanto, ASP.NET ylos servicios WCF se ejecutan simultá-neamente (side-by-side). Cualquier peti-ción WCF es capturada por IIS, rediri-gida a ASP.NET y procesada por latubería HTTP (HTTP pipeline). Encierto momento, concretamente cuan-
do se lanza el evento PostAuthenticate-Request, la infraestructura de aloja-miento de WCF intercepta la petición,comienza a procesarla y nunca devuel-ve el control a la tubería HTTP. Entreotras cosas, esto quiere decir que losmódulos HTTP programados paraatender las peticiones en una etapa pos-terior de la tubería nunca interceptaránlas peticiones WCF. En el escenariopredeterminado, el servicio WCF notiene acceso al objeto de contextoHTTP de ASP.NET. Si un servicioWCF intenta usar la propiedad Http-
y procesar las respuestas. Así pues, elasunto tiene que ver con la simplicidad.Si necesitas proteger datos sensiblesmientras se transmiten, dispones delprotocolo HTTPS y de los mecanis-mos de cifrado correspondientes. Sinecesitas autenticación, necesitas bus-car otras soluciones alternativas. Lacomplejidad y la potencia del esquemawsHttpBinding estaría un poco fuera delugar y resultaría algo excesiva.
Hay bastantes diferencias entrebasicHttpBinding y wsHttpBinding en lorelativo al intercambio de paquetes SOAPa bajo nivel. El esquema basicHttpBin-ding existe solamente para permitir elsoporte de servicios al antiguo estiloASMX basados en el perfil WS-Basic-Profile 1.1. En particular, existe para satis-
facer las necesidades de los clientes queno tienen instalado .NET 3.0 o superior.Para las muchas máquinas que todavíaejecutan Windows 2000 y no pueden seractualizadas a .NET 3.x, basicHttpBin-ding es la única forma de comunicarsecon el mundo exterior a través de servi-cios. En suma, este tipo de enlace existesobre todo por razones de compatibili-dad.
Con basicHttpBinding no se dispo-ne de soporte para mensajería segura,al menos por defecto, (o sea, sin lasextensiones WS-*). Por ejemplo, cuan-do un cliente llama a una operación deun servicio, todos los datos de respues-ta son enviados "en claro" dentro de unpaquete SOAP perfectamente legible.Además, este esquema tampoco sopor-
ta fiabilidad (reliability) ni entrega orde-nada. Esto quiere decir que si se pier-de una llamada en el camino, el clien-te no será informado de este hecho,agotando su tiempo de espera (timeout)sin poder determinar si el servidor reci-bió la llamada. La ausencia de entregaordenada implica que si un cliente lan-za múltiples peticiones, no hay garantíaalguna de que los mensajes de peticiónlleguen al servidor en el mismo ordenen que fueron enviados.
En suma, que no habría ningunarazón para no utilizar wsHttpBinding enclientes que consumen servicios WCF.Pero en Silverlight, así como enASP.NET AJAX, este esquema no estásoportado.
En ASP.NET AJAX, wsHttpBindingno está soportado porque escribir enla pila cliente de WCF medianteJavaScript sería bastante complicado,como también lo sería la inclusión defirmas digitales y el cifrado de la men-sajería. En Silverlight se dispone de unpotente entorno de desarrollo, peroaún existen limitaciones significativasen lo relativo a la construcción de lapila cliente de WCF (por ejemplo, encuanto a la seguridad de los mensajeso las factorías de canales), ya que lamayoría de las características requie-ren confianza total.
dotN
etM
anía
<<
55
Tod
otN
et.q
a@
dot
netm
ania
.com
Tod
otN
et.q
a@
dot
netm
ania
.com
dnm.todonet@qa<<
¿Tiene alguna ventaja utilizar el modo de compatibilidad para servicios WCF? ¿O es solamente para clientes AJAX?¿Puede darnos alguna pista?
Figura 1. Modos de seguridad basicHttpBinding en Silverlight
Context.Current, siempre recibirá un valor nulo comorespuesta. Además, al autorizar la petición, el modelo deseguridad de WCF no reconoce ninguna lista de controlde accesos (ACL) que pudiera haber sido incluida en elfichero .svc. De forma similar, el modelo de seguridadde WCF no se adhiere a ninguna de las reglas de auto-rización basadas en URL y especificadas en el nodo <aut-horization> del fichero de configuración. Por último, laspeticiones WCF siempre se ejecutan bajo la identidaddel proceso IIS, independientemente de los valores depersonificación (impersonation) establecidos en la confi-guración.
En circunstancias normales, esas diferencias no cons-tituirán un problema insoluble. Por otro lado, WCF hasido diseñado específicamente para ser independiente delprotocolo y transporte utilizados. Su independencia deASP.NET (que fue diseñado de un modo muy depen-diente de IIS y HTTP) es perfectamente normal.
¿Cuándo es, por tanto, necesario el modo de com-patibilidad? Cuando cualquiera de las características antescitadas limiten nuestra potencia de programación. Porejemplo, supongamos que por razones de seguridad senecesita autenticar al usuario antes de que pueda proce-der a una llamada a un servicio WCF. Entonces, mos-tramos una página de identificación para recoger las cre-denciales del usuario. Si la autenticación es correcta, segenera una cookie que se transmite en las peticiones sub-siguientes. Si se quiere comprobar las credenciales des-de el servicio WCF, o si se desea utilizar la autorizaciónbasada en URL para proteger el acceso al fichero .svc,no es posible mantener el servicio WCF y la parteASP.NET débilmente acopladas. Aquí es donde inter-viene la compatibilidad.
Se activa el modo de compatibilidad en el fichero deconfiguración, tal como mostramos aquí:
Además, es necesario que cada servicio dé su propiaaprobación explícita al modelo. Esto se hace añadiendoa la clase del servicio (no al contrato) el atributo AspNet-CompatibilityRequirements, como muestra el siguientecódigo:
Los servicios WCF han sido diseñados para ser inde-pendientes del tipo de enlace y del transporte. Al habi-litar el modo de compatibilidad ASP.NET, estamos rom-piendo esta regla, al hacer que el servicio sea dependientede IIS como alojamiento y de HTTP como protocolode transporte. Por otro lado, los servicios que son lla-mados normalmente desde una capa AJAX son general-mente servicios específicos para AJAX, por lo cual habi-litar la compatibilidad ASP.NET en estos casos es inclu-so una opción natural.
No mucho, me temo. En efecto, se necesitan privile-gios administrativos para instalar el complemento deSilverlight. Hay que tener en cuenta, sin embargo, queesta restricción no es exclusiva de Silverlight, sino quees aplicable a cualquier complemento para un nave-gador. Esto significa que los usuarios individuales deuna red corporativa no pueden instalarlo simplemen-te navegando a una página que utilice Silverlight. Almismo tiempo, es competencia de los administrado-res desplegar el complemento para cada máquina bajo
su control. Para facilitar las cosas a los administrado-res, Microsoft ha incluido Silverlight como una actua-lización opcional mediante Windows Server UpdateServices (WSUS) y también mediante Microsoft Upda-te. De esta forma, los administradores pueden con-trolar la instalación de Silverlight en sus organizacio-nes e incluso programar la instalación como tarea desegundo plano. Como resultado, los usuarios podránvisualizar contenido Silverlight sin requerir ningúnprivilegio administrativo.
“How virtualization improves softwa-re development” es un excelente artícu-lo de Daniel Dern sobre las ventajas de
la virtualización en todas las fases del desarrollo, donde se ana-liza cómo han sido los programadores (para crear sus entornosde pruebas) los que más han hecho por introducir estas técnicasen la empresa. Disponible en http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9127785&source=rss_news.
Mike James discute en “C# 4.0goes dynamic - a step too far?” lasnuevas características de C# 4.0 en
cuanto a la adopción de opciones propias de los lenguajes diná-micos. Lo bueno, lo malo y lo que quedará pendiente. Puedeleerse en http://www.developerfusion.com/article/9789/c-40-goes-dynamic-a-step-too-far.
Project Astoria Team Blog. El seguimientoconstante de los avances del equipo dedesarrollo de ADO.NET Data Services,en http://blogs.msdn.com/astoriateam. Conwebcasts accesibles desde ahí y vídeos desus actividades.
Pluralsight. Muy buenos artículos aportaeste portal de bloggers, avalado por cono-cidos divulgadores como Fritz Onion,
quien acaba de publicar “Creating JSON-enabled WCF servi-ces in .NET 3.5”. Pero hay mucho material valioso ahí dentro.Recomendamos un vistazo a la lista de colaboradores actualiza-da: http://www.pluralsight.com/community/blogs/fritz.
Wise Registry Cleaner 3.92. Herramienta para mantener elRegistro de Windows limpio de los restos de programasdesinstalados, con un motor de reconocimiento rápido yseguro. Tras el análisis, permite que el usuario estudie –silo considera necesario– los problemas encontrados y sudescripción detallada. Además, todos los cambios reali-zados pueden deshacerse posteriormente. Disponible enhttp://www.majorgeeks.com/download5437.html.
documentos en la red
utilidades del mes
sitios del mes
El reconocimiento técnico de los grandes genios de la informática
Ninguna tecnología se ha desarrollado más que la informática ni ha pasado aformar parte de la vida cotidiana en los últimos 20 años de una forma tan espec-tacular como las múltiples aplicaciones que la informática tiene hoy. Sin embar-go, el reconocimiento de aquellos que han hecho los grandes descubrimien-tos no ha trascendido a la cultura popular. Ya, ya sé que todo el mundo cono-ce a Bill Gates y Paul Allen, Steve Jobs y Steve Wozniak y a algunos másde los CEO de las grandes compañías. Un cierto porcentaje de programado-res conoce también a los grandes creadores de lenguajes, como Brian Ker-nighan y Dennis Ritchie (autores del lenguaje C), Bjarne Stroustrup (crea -dor de C++), James Gosling (Java), Anders Hejlsberg (autor principal deC# y de buena parte de la plataforma .NET), y poco más… Tim Berners-Lee y Vinton Cerf se convirtieron en personajes populares en nuestro país araíz de la obtención del Premio Príncipe de Asturias, por su labor fundamen-tal en la popularización de Internet. Pero al lado de los cientos de innovacio-nes que se han sumado para hacer posible lo que la informática es ahora, son,como dice el dicho popular, “cuatro gatos”…
No obstante, sí que existen reconocimientos “oficiales” de estos logros,y también otros de tipo más corporativo, que sus promotores están empeña-dos en dar a conocer.
En el lado oficial, cabe destacar los Premios Alan Turing (Turing Awards),concedidos anualmente por la Association for Computing Machinery, de EE.UU.,que han ido ganando importancia a través de los años. En esta revista tuve lasuerte de publicar una entrevista -dotNetManía nº12- con uno de los recepto-res de este prestigioso premio, James Gray, tristemente desaparecido en el marel año pasado. Estos galardones han premiado a algunos de los citados más arri-ba, de los que se puede decir sin lugar a duda que “son todos los que están”, aun-que –por razones de espacio- no están todos los que son. Con los Nobel pasa lomismo. Si el lector quiere echar un vistazo a los resúmenes biográficos de todoslos Premios Turing hasta el año 2007 (el de 2008 se nombrará en breve), pue-de verlos en mi página http://www.elavefenix.net/Biografias.aspx.
Pero éstos no son los únicos reconocimientos públicos vinculados a laInformática. Al pairo de los anteriores han ido surgiendo otros, más o menosespecíficos, que premian diversos aspectos de la actividad que nos ocupa. Enesta categoría, la medalla John von Neumann es quizá la más reconocida, ycuriosamente ha duplicado algunos de sus premios, como sucede con los entre-gados a Ole-Johan Dahl y Kristen Nygaard los noruegos creadores de lateoría de la programación orientada a objetos, o Douglas Engelbart (creadordel ratón, investigador de Microsoft Research y perceptor del Premio Turingen 1997 y del Von Neumann en 1999). Pero todavía hay más, como los pre-mios Dijkstra (computación distribuida), Eckert-Mauchly (arquitectura de orde-nadores), Loebner (Inteligencia Artificial), Grace Murray Hopper (de tipogeneral), Gödel (Teoría de la Computación), Donald Knuth (Teoría de la Com-putación en la práctica), y un largo etcétera de un carácter más particular.
Pero las grandes corporaciones también desean que aquellos que han sidoel “alma mater” de los desarrollos que después se han convertido en popularesobtengan la visión pública que merecen. En el caso de Microsoft, esta menciónrecibe el nombre de “Technical Fellow”, y entre otros, la poseen los antes cita-dos Hejlsberg y Engelbart, además de Butler Lampson (otro perceptor devarios de los premios anteriores), Dave Cutler, Brad Lovering o Mark Rus-sinovich. La lista completa (22 miembros) aparece en la página http://www.micro-soft.com/presspass/exec/techfellow, y el propio Bill Gates afirmó recientemente queespera que a este grupo se unan Ray Ozzie y Craig Mundie, quienes actual-mente lideran la visión tecnológica de la compañía.
firma.firma.firma.firma
Technibble’s Computer Repair Utility Kit. El sitio Technibbleofrece esta utilidad para la gente de TI (y para cualquie-ra a quien le guste tener su ordenador a punto), que esuna pequeña joya. Technibble’s Computer Repair UtilityKit es un conjunto de 57 utilidades que pueden ejecutar-se desde un USB Pen Drive, y que incluyen herramien-tas para ficheros, para la red, reparadores, utilidades deseguridad y mucho más. Se puede descargar gratuitamentede la dirección: http://www.technibble.com/computer-repair-utility-kit.
