MSDN Blogs
  • WarNov Developer Evangelist

    Stairway to Azure (3): Componentes de Cómputo y Almacenamiento

    • 4 Comments
    Descarga la presentación PowerPoint de este Post.
     En mi post anterior, vimos por qué en determinado momento, es ventajoso tener alguien que se preocupe por el manejo de la infraestructura de nuestras aplicaciones en vez de nosotros. Y observamos que esto nos dejaría libres para preocuparnos únicamente por desarrollar la lógica de nuestras aplicaciones. Ya no es necesario comprar, instalar y operar sistemas de IT. Además solo pagaríamos por el cómputo y almacenamiento usado (como con los servicios públicos) y no una tasa fija que solo se requiere para ciertos picos. Finalmente, si enfocamos correctamente nuestras aplicaciones, estas pueden escalar muy fácil tomando ventaja de los enormes centros de datos que ofrece Microsoft para hospedar nuestras aplicaciones. Por ejemplo; si decidiéramos crear el siguiente “Facebook” sería muy últi Windows Azure ya que soporta trabajos de presentación (Web Role) y trabajos de proceso (Worker Role). Además si es una iniciativa con poco presupuesto inicial, es ideal ya que a medida de que se tengan más usuarios y se requiera escalar el sistema, se tendrán más recursos para adquirir dentro de Windows Azure.  

    Nuevamente, eso no implica que todo lo desplegaremos en Azure. La idea no es tener únicamente  SaaS sino también S+S. Así que por ejemplo las aplicaciones que hoy en día corren dentro de una organización (on-premises) podrían almacenar datos en la nube o usar otros servicios de la misma. Aplicaciones que corren en el escritorio o teléfonos móviles pueden usar los servicios de la nube para hacer sincronización de datos. 

    Toda esta maravilla requiere de aplicaciones que la exploten! Y para lograr dichas aplicaciones, necesitamos de una plataforma para construirlas. Esta plataforma es provista por Windows Azure y está compuesta por un grupo de tecnologías que nos proveen servicios a nosotros como desarrolladores.  

     

     

    Componentes de Azure

    En Windows Azure básicamente encontramos tres componentes principales:

    Windows Azure

    Ambiente basado en Windows (en esta edición es Server 2008), para ejecutar aplicaciones y almacenar datos en los centros de datos de Microsoft.

    SQL Azure

    Provee servicios de datos basados en SQL Server

    .NET Services

    Infraestructura distribuida para usar con aplicaciones locales y hospedadas en la nube.

    Estos componentes los podemos apreciar en la siguiente ilustración. En este post exploraremos en detalle el componente Windows Azure (Cómputo y Storage) y posteriormente observaremos Sql Azure y .NET Services.

    Windows Azure

    Comencemos entonces con Windows Azure:

    Overview

    Como podemos observar en la gráfica, este componente se subdivide en tres elementos: la estructuta principal o Fabric, el componente de cómputo y el componente de almacenamiento (storage). Empecemos viendo en detalle el componente de cómputo.

    Servicios de Cómputo

    Windows Azure corre sobre una gran cantidad de máquinas, todas ubicadas en los datacenter de Microsoft y accesibles vía internet. Todas estas máquinas conforman un todo que le da el poder y escalabilidad necesarios. Aunque al principio solo se iban a poder ejecutar aplicaciones .NET hoy en día, esta plataforma permite ejecutar aplicaciones nativas de Windows (esto lógicamente comprende todos los lenguajes de programación tradicionales que hoy en día sirvan para correr aplicaciones sobre Windows Server 2008).
    En Windows Azure, una aplicación típicamente tiene múltiples instancias y cada una corre una copia de todo o una parte de la aplicación. Cada instancia corre en su propia máquina virtual. Estas VMs están sobre Windows Server 2008 x64. Las aplicaciones se instancian en uno de dos roles, según escoja el desarrollador. Web Role, o Worker Role:

     

    Azure

     El Web Role corre sobre IIS7 y acepta los llamados HTTP o HTTPS (tecnologías: ASP.NET, WCF, todas las que trabajen con IIS). El balanceo de carga es automático, gracias al Load Balancer incluido en la plataforma.
    El Worker Role no puede aceptar peticiones directas desde el mundo exterior. Típicamente estos roles adquieren sus entradas a través de colas en el Windows Azure storage. Estos mensajes sí pueden provenir de una aplicación exterior o de un Web Role. Son procesados y la respuesta se puede poner en una cola, o enviarse directamente al mundo exterior (esto último sí es permitido).
    Independientemente del tipo de rol en una VM, siempre existe un Agente de Azure que permite la interacción del rol con el resto de la aplicación y la plataforma.
    Aunque es algo que puede cambiar en el futuro, en la actualidad Windows Azure mantiene una relación 1:1 entre VMs y cores físicos de procesador. Esto obviamente garantiza el performance de la aplicación que sea predictible (cada instancia tiene su propio core dedicado; esto también significa que no hay un límite arbitrario en el tiempo de proceso concedido a una instancia en especial). Sin embargo si se desea aumentar el performance, el dueño de la aplicación podría decidir crear más instancias de la misma, solo modificando el archivo de configuración. De esta manera, Windows Azure detecta el requerimiento y ajusta una nueva VM con su respectivo core. Si en algún momento alguna instancia falla, Azure lo detecta e inicia una nueva.

    Esto genera una notoria implicación: Para ser escalable, las instancias de Windows Azure Web role, deben ser stateless (no manejar estado en sesión o aplicación por ejemplo). Todo estado requerido ha de ser escrito en los mecanismos de storage de Windows Azure, o pasados al usuario final por medio de cookies por ejemplo. Además debido al load balancer, no hay forma de garantizar que múltiples peticiones de un mismo usuario sean enviadas a un mismo Web Role.
    Este tipo de implicaciones hace que el pasar aplicaciones a la nube o crearlas destinadas para ellas, no sea completamente transparente comparado con el modelo on-premises. Sin embargo, los cambios son muy sutiles (usar ADO.NET Data Services –compatible con Azure Storage-, tener en cuenta el modelo de colas para los Worker Role, etc.)
    Por esto, para los desarrolladores, trabajar con Windows Azure, es muy similar a crear aplicaciones tradicionales Windows. Microsoft provee templates para Visual 2008 que permiten crear Web Roles, Worker Roles y combinaciones de los dos. Los desarrolladores son libres de usar cualquier lenguaje de programación Windows. Todo esto viene en un SDK de Azure que también contiene una versión de ambiente Windows Azure que corre en la máquina del desarrollador. Este ambiente es conocido como Windows Azure Development Fabric e incluye Windows Azure Storage, un agente Windows Azure y todo el resto de tecnologías que requiere una aplicación para correr en la nube.
    Un desarrollador puede crear y depurar su aplicación usando este simulacro local y luego desplegar la aplicación a Windows Azure, cuando ésta esté lista, aunque en la nube hay cosas que son realmente diferentes. Por ejemplo, no es posible hacer el attach de un debugger a una aplicación en la nube. Así que básicamente para hacer el debugging de una aplicación en la nube, el mecanismo principal sería la escritura a los logs de Windows Azure, vía el agente de Azure.
    Otros servicios provistos incluyen por ejemplo el envío de mensajes desde los agentes a Windows Azure, quien los captura y reenvía por medio de emails, mensajería instantánea o cualquier otro mecanismo especificado. Además también se puede especificar a Windows Azure que detecte fallas automáticamente y envíe alertas. También está disponible información acerca de consumo de recursos tales como tiempo de proceso, ancho de banda entrante y saliente y almacenamiento.

    Cuando el desarrollador ha depurado completamente su aplicación de manera local, ésta ha de ser instalada en un proceso de dos etapas. Primero se sube la aplicación al área de staging en Azure. En este momento, la aplicación queda identificada con un nombre DNS que tiene la forma <GUID>.cloudapp.net, donde <GUID> representa un identificador asignado por Windows Azure. Este nombre es asociado con una dirección IP virtual (VIP) que identifica al balanceador de carga a través del cual la aplicación será accedida. En el momento en que se decide pasar ya la aplicación a producción, se usa el portal de Windows Azure para solicitar el paso a producción. En este caso, Azure automáticamente cambia la entrada en sus servidores DNS para asociar la VIP con el nombre de producción que el desarrollador ha escogido; por ejemplo: myapp.cloudapp.net. (Es posible usar un nombre de dominio personalizado, sencillamente creando un DNS alias usando un CNAME estándar). Otro punto para resaltar aquí: las IPs reales de las aplicaciones jamás son reveladas.

    Esto brinda un fuerte componente de seguridad.

    Servicios de Almacenamiento

    Esta parte de la plataforma también provee un tipo de almacenamiento: Azure Storage. Que es distinto a SQL Azure (otra parte de la plataforma). El almacenamiento Azure no es relacional. Su lenguaje de consulta tampoco es SQL. Es un almacenamiento mucho más sencillo, pero más escalable y más rápido que un almacenamiento relacional. Básicamente hay tres tipos de almacenamiento Azure:

    Storage

     

    1.       BLOBS:  (Binary Large Objects). Prácticamente, archivos. Los requerimientos de File System de nuestras aplicaciones en la nube, se suplen con los blobs. Un blob puede ser de hasta 50Gb de espacio y se encuentra dividido en bloques, de manera que cuando se hacen transferencias y ocurren fallos, la transferencia puede continuar desde el último bloque transferido correctamente.

    2.     Tablas: Los Blobs son la opción justa para algunas situaciones. Pero para otras son muy poco estructurados. Son muy sencillos de entender; pero para permitir a las aplicaciones trabajar con datos de una manera más formal se proveen las tablas. Estas tablas no son tablas relacionales y tienen su complejidad:
           
            Tables

    De hecho, a pesar de que se llaman tablas, los datos que ellas contienen realmente se encuentran almacenados en una jerarquía simple de entidades que contienen propiedades. Cada propiedad tiene un nombre, un tipo y un valor. Varios tipos son permitidos incluidos: Binary, Bool, DateTime, Double, GUID, Int, Int64 y String. Una propiedad puede tomar diferentes tipos dependiendo de los valores almacenados en ella. De hecho, no hay obligación de que todas las propiedades en una entidad tengan el mismo tipo. El tamaño para cada entidad puede ser de hasta 1MB y siempre es accesada como una unidad. Cuando se lee una entidad se retornan todas sus propiedades y al escribir una, esto se hace atómicamente de manera que se reemplazan todas sus propiedades. Y en vez de usar SQL, una aplicación accesa los datos de una tabla usando las convenciones definidas por ADO.NET Data Services (no ADO.NET convencional), o REST. La razón para este tipo de solución, es que nos permite escalar el almacenamiento de una forma tal, que podemos distribuir nuestros datos en distintas máquinas (muchas más de las que se posibilitan con bases de datos relacionales tradicionales); de hecho, una sola tabla en SQL Azure puede ser de terabytes!

    3.    QUEUES: Los blobs y las tablas están enfocados en almacenamiento y acceso de datos. La tercera opción en Windows Azure son las colas, que tienen un propósito muy distinto. Una función principal de las colas es proveer un mecanismo para que las instacias de tipo Web Role se puedan comunicar con las instancias de tipo Worker role. En la siguiente gráfica, se describe el funcionamiento de las colas. En un escenario típico, un rol acepta trabajos de los usuarios (paso 1). Para pasar esos requerimientos a los worker role, se escribe un mensaje en la cola (paso 2). Este mensaje, puede ser de hasta 8kb y es posible usarlo para que contenga URIs apuntanto a blobs o entidades en tablas en caso de que se requiera transmitir más información. El worker lee los mensajes de su cola (paso 3) y ejecuta el trabajo como tal. Una vez leído el mensaje, éste no se borra. En vez de esto, el mensaje se hace invisible a otros lectores por un período de tiempo (por defecto 30 seg). Cuando el worker ha completado su trabajo, en ese momento se borra explícitamente de la cola. (paso 5)
            QUeues


    Separar las instancias web de las worker tiene sentido porque libera al usuario de tener que esperar a que una tarea larga sea procesada y también hace la escalabilidad más simple, dado que solo sería necesario agregar más instancias. Pero por qué hacer que las instancias borren explícitamente los mensajes? Esto se hace para manejar fallos. De esta manera si  un worker que está haciendo el trabajo indicado falla, el mensaje no se borrará de la cola.  Así que cuando vuelva a estar visible, el mensaje reaparece en la cola para ser leído por otro worker. Y de esta manera se proteje el mensaje de fallos.

    Independientemente del tipo de almacenamiento, todo dato almacenado es replicado tres veces, para garantizar redundancia de datos y tolerancia a fallos.

    El storage de Windows Azure puede ser accedido por aplicaciones de Windows Azure o cualquier otra. En ambos casos, todos los tres tipos de storage pueden consultarse a través de REST. Todo es nombrado usando URIs y accesado con operaciones HTTP estándares. No obstante, un cliente .NET podría usar ADO.NET Data Services o LINQ para acceder más cómodamente a esta información. Pero un cliente java  usaría REST estándar. Por ejemplo, un blob puede ser leído con un HTTP GET contra un URI formateado así:

    http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName>

    De manera similar, una consulta sobre una tabla sería:

    .table.core.windows.net/?$filter=http://<StorageAccount>.table.core.windows.net/<TableName>?$filter=<Query>

    y una cola se accesaría:

    .queue.core.windows.net/http://<StorageAccount>.queue.core.windows.net/<QueueName>

    La Estructura (Fabric)

    Todas las aplicaciones de Windows Azure y todos sus datos en el Storage, residen en alguno de los centros de datos de Microsoft. Dentro de ese centro de datos, el conjunto de máquinas dedicadas a Windows Azure se organizan en una fábrica tal como lo muestra la siguiente gráfica:

     

    Fabric

     

    Tal como se aprecia, la Estructura Azure es un gigantesco grupo de máquinas administrado por un componente de software llamado Fabric Controller. Este controlador es replicado a través de un grupo de 5 a 7 máquinas y es dueño de todos los recursos en la estructura: computadoras, switches, balanceadores de carga y más. Dado que el controlador se comunica con un “Fabric Agent” en cada máquina, también tiene información de cada aplicación en la estructura. Como punto a resaltar, puedo mencionar que el Storage también aparece ante el controlador como una aplicación más. Así que el controlador no conoce los detalles del storage; esto último indica obviamente que el almacenamiento es autocontrolado. Es decir; el Storage, es solo una aplicación más dentro de la estructura, que se administra autónomamente.

    Este amplio conocimiento le da la capacidad al Fabric Controller de cumplir múltiples funciones como monitorear todas las aplicaciones que están corriendo y de esta manera ser capaz de dar información en vivo, de qué es lo que está pasando en la estructura. Administra los sistemas operativos teniendo en cuenta aspectos como las actualizaciones de los Windows Server 2008 que corren en las VMs de Azure. También decide dónde deben correr las aplicaciones, escogiendo los servidores físicos para optimizar la utilización del hardware. Para lograr esto, el controlador depende del archivo de configuración que es subido con cada aplicación a la nube. Este archivo provee una descripción basada en XML de las necesidades de la aplicación: cuántos roles web necesitará, cuantos roles de trabajo y otros detalles. Cuando el controlador recibe una nueva aplicación, éste usa su archivo de configuración para determinar cuántos roles de cada tipo ha de crear. Una vez creadas estas VMs, el controlador las monitorea. Si una aplicación requiere 5 instancias de Web Role y una muere, el controlador automáticamente reiniciará una nueva.

    Esta creación de instancias debe realizarse inteligentemente. Por ejemplo, suponiendo que además de las 5 instancias web el desarrollador pide cuatros instancias worker. Una asignación ingenua podría poner todas estas instancias en máquinas en el mismo rack servidos por el mismo switch. Si el rack o el switch fallara, la aplicación entera quedaría no disponible. Dadas las metas de alta disponibilidad de Windows Azure, hacer que una aplicación dependa de puntos sencillos de falla como este, no es una buena idea.

    Para evitar esto, el controlador agrupa las máquinas en conjuntos llamados “Dominios de Falla”. Cada dominio es parte de un data center que independizaría las fallas únicamente a su contenido. Eso se ilustra en la siguiente gráfica:

    Failure

    En este ejemplo sencillo, la aplicación está corriendo en dos instancias Web y el datacenter está dividido en dos Dominios de Falla. Cuando el controller despliega la aplicación, se establece una instancia de Web Role en cada uno de los dominios. Este arreglo significa que una falla en el hardware no va a provocar que toda la aplicación se caiga.

    Hasta aquí vimos todo lo relacionado al componente de Windows Azure. En mi post Stairway to Azure (4): Sql Azure y .NET Services, veremos la descripción de estos otros dos componentes.

  • WarNov Developer Evangelist

    Antivirus Gratuito: Microsoft Security Essentials

    • 0 Comments

    Cansado de buscar un antivirus gratuito en el que en verdad pueda confiar?

    Ya no es necesario buscar más! Microsoft ofrece uno completamente gratis y no solo es un antivirus, sino toda una suite de seguridad que respeta la libre elección de sus usuarios, su privacidad y no exige registro ni identificación alguna:

    Se trata de Microsoft Security Essentials que brinda seguridad en la que usted puede confiar;  es fácil de obtener y utilizar y brinda una protección silenciosa que no interfiere con el performance de su máquina. Brinda protección en tiempo real para atender las necesidades de seguridad continua de un PC con Windows, lo que ayuda a protegerlo contra virus, spyware y otras amenazas maliciosas. 

    Cualquier usuario del HOGAR con Windows versiones Windows XP, Windows Vista o Windows 7 que tenga una versión ORIGINAL de Windows lo puede descargar GRATUITAMENTE de la RED y usarlo indefinidamente. Es Gratuito y exclusivo para los usuarios con una versión Original de Windows. (Para entornos empresariales está disponible el producto Microsoft Forefront). 

    Los únicos requisitos para correr este software son: Cualquiera de las versiones de 32 o 64 bits de Windows XP SP2 y superior, Windows Vista y Windows 7 incluyendo el modo XP.

    La idea de ofrecer disponibilidad gratuita de este producto únicamente con copias originales de Windows, obedece a que la protección en tiempo real como aquella que se encuentra en Microsoft Security Essentials es una gran herramienta en la lucha contra software malicioso conocido; sin embargo para mejorar el estado general del ecosistema también se requiere tratar el malware en la fuente de distribución. Las fuentes de software falsificado y soluciones temporales de activación maduran con el malware. Una vez infectados, los PC con software no original están más propensos a convertirse en hosts de malware, que propagan software malicioso a otras máquinas en el ecosistema. Conducir más sistemas al software original tiene el potencial de atender mejor las necesidades comerciales y de seguridad del ecosistema en general. Si el PC no aprueba la validación de originalidad, la instalación de Microsoft Security Essentials termina y al usuario se le envía a información sobre cómo resolver los problemas relacionados con software original.

    Uno de los detalles especiales de este producto, es que los usuarios de Microsoft Security Essentials contarán con acceso al soporte de la comunidad y de correo electrónico sin costo alguno.

    Microsoft Security Essentials no estará disponible como una descarga crítica de Windows. El instalador estará disponible como una descarga individual sin costo pero utilizará el servicio Microsoft Update tanto para las descargas de firmas como para las actualizaciones de producto.

    Se puede descargar de http://www.microsoft.com/security_essentials y no se requiere que los consumidores ingresen una ID de Windows Live ni registro para descargar la solución.

    Microsoft ya ha liberado productos para proteger el software de programas malintencionados como Windows Defender que detecta y elimina sólo spyware conocido (tecnología que ayuda a recopilar información acerca de una persona u organización sin su conocimiento o consentimiento). Sin embargo, no está diseñado para brindar protección contra la gama completa de software malicioso, y en específico no evita que virus, gusanos, troyanos, y otro software malicioso infecten su máquina. La nueva solución sin costo será una solución antimalware completa que se encarga de estas amenazas. Esto no significa que Microsoft Security Essentials esté diseñado para reemplazar a Windows Defender. Pero si usted ejecuta Microsoft Security Essentials, no necesita ejecutar Windows Defender. Microsoft Security Essentials deshabilita Windows Defender para administrar la protección en tiempo real del PC, incluyendo antivirus, rootkits, troyanos y spyware.

    Aparte de ser gratuito y ofrecer tantas ventajas, Microsoft cree en la elección del cliente. Al ofrecer Microsoft Security Essentials como una descarga individual e independiente, Microsoft ofrece a los usuarios de Windows la opción de elegir, gratis o de otro tipo, la solución de seguridad de PC que se ajusta mejor a sus necesidades individuales. Además también protege la privacidad de sus usuarios, Microsoft Security Essentials no desencadena un cambio en el estado del PC con Windows sino que lee el valor de originalidad almacenado en la máquina donde está disponible, o de otra manera invoca una API para que valide dónde no exista un estado local. No se ve ni recopila información personal como parte de la validación de originalidad.

    Conózcanlo, instálenlo y recomiéndenlo a sus conocidos para evitarles tediosas búsquedas de antivirus gratuitos!

  • WarNov Developer Evangelist

    Stairway to Azure (2) Adquiriendo las cuentas de acceso.

    • 0 Comments

    En la primera entrega de esta serie de posts acerca de Windows Azure, estuve recorriendo todo el camino en la historia de Software más Servicios y relacioné un video que muestra de forma muy rápida esta historia y nos deja listos para comenzar a usar Windows Azure como alternativa de S+S propuesta por Microsoft.

    Vimos como Windows Azure permite hospedar en la nube servicios de negocio y de base de datos y que tiene puntos de conexión para comunicarnos con las aplicaciones "on-premises".

    Cuando trabajamos con Windows Azure, básicamente nos descargamos un SDK y unas herramientas que se instalan sobre nuestro Visual Studio y IIS, con el fin de generar un Windows Azure "Local" sobre el cual podemos hacer pruebas de los desarrollos para Windows Azure. Obviamente, los servicios de Azure tienen su costo (posteriormente estaemos hablando de esto). Pero como también es obvio, necesitamos tener la oportunidad de probar la experiencia, antes de pagar por una suscripción.

    Por este motivo, Windows Azure ofrece un trial, para que podamos poner en el Windows Azure real las aplicaciones que desarrollemos usando el Azure Virtual Local. Para acceder a estas cuentas trial, es necesario solicitar un token, que se toma su tiempo en ser asignado a nosotros (algunos días). Para solicitarlo, primero es necesario registrar nuestra cuenta de Windows Live Id (anteriormente Passport.NET) en el sitio de Microsoft Connect. Y luego de esto, llenar una información de registro específica para acceder al token. Después, esperamos algun tiempo mirando ansiosamente el correo todos los días, hasta que descubrimos que tenemos el tan preciado token. Una vez con ese token en nuestro poder, procedemos a redimirlo en el sitio de Windows Azure de acuerdo a las instrucciones que vienen en el correo y en adelante, podremos subir nuestras soluciones a la nube.

    He querido postear esta información antes de explicar realmente como programar para Azure, pues me gustaría que la audiencia vaya adelantando el proceso de adquisición de tokens, para que cuando ya sepan cómo y tengan desarrollos para Windows Azure, ya hayan redimido su token y puedan probar sus aplicaciones online. Para este fin, también he publicado un video, que muestra más detalladamente los pasos a seguir:

    Los espero en una nueva entrega donde comenzaremos con el típico "Hola (mundo) Nube"

  • WarNov Developer Evangelist

    Métodos Parciales (Partial Methods)

    • 0 Comments

    Una gran adición del Framework 2.0 en cuanto a codificación, fueron las clases parciales. Surgieron como una excelente solución sobretodo para los generadores automáticos de código, pues anteriormente cuando no habían clases parciales y uno trabajaba sobre una clase generada por alguna herramienta, el trabajo ejecutado se perdía cada vez que se regeneraba dicha clase.

    Gracias a las clases parciales entonces, uno podía generar un archivo "paralelo" que hacía referencia a la misma clase, pero que no se veía afectado en las regeneraciones automatizadas. Todo esto con la gran ventaja de que a pesar de que estuvieran en archivos distintos, la clase aparecían al resto del mundo como una sola (intellisense, compilación, etc).

    Otro uso interesante, es la posibilidad de dividir grandes clases en unidades con funcionalidades comunes, para obtener una mayor administrabilidad de las mismas y para permitir que varios desarrolladores estuviesen trabajando sobre una misma clase (en las versiones parciales en archivos distintos)  al mismo tiempo.

    Ya para el Framework 3.5 se incluyeron los métodos parciales que van un paso más allá con este concepto.

    La idea es que en una clase parcial se incluye la firma del método (tiene que ser privado y con tipo de retorno void) y en otra clase se "implementa". Lo pongo entre comillas, porque implementar me lleva a pensar en una interfaz, donde obligatoriamente se tiene que implementar los métodos establecidos por ella. Con los métodos parciales no existe esa OBLIGACION. El desarrollador decide si quiere "implementar" o no los métodos parciales que define la clase parcial.

    Para saber qué metodos parciales incluye una clase, basta con recurrir al intellisense y escribir "partial" y dar espacio; inmediatamente saldrán todos los métodos parciales disponibles.

    Esto resulta muy últil también en el proceso de personalización de código generado automáticamente, tal como pasa con la generación del modelo de datos que ofrece el Entity Framework. Las clases generadas por este framework, agregan métodos parciales para que se puedan controlar los cambios a los atributos en las clases generadas. Entonces si el desarrollador quiere establecer un control granular sobre estos cambios, implementa los métodos parciales en sus clases parciales externas.

    Qué ventajas ofrece esta metodología comparada con una de Interfaces?

    Si se fuera a autogenerar código con una herramienta como el Entity Framework, basado en una interfaz o en una clase base (con métodos virtuales o abstractos), obviamente la implementación de los métodos dictados por la interfaz quedarían en el código autogenerado o se haría muy complicado el proceso de escoger el archivo donde se quiere generar estos métodos y si se quieren generar o no pues tal vez ya han sido modificados.

    Además hay otra ventaja y es que cuando los métodos parciales no son implementados, entonces ni sus firmas ni sus llamados se incluyen en la compilación del código, lo que hace el proceso de compilación y el resultado de la misma, mucho más liviano que cuando se usan interfaces, o cuando se crean métodos virtuales o abstractos.

    En conclusión, vemos como muchas de las innovaciones del Framework .NET tienden a hacer más práctica la programación, sin perder el formalismo que lo ha caracterizado a través de su historia. La aparición de métodos parciales son una buena noticia y entender muy bien su uso nos permitirá desarrollar excelentes piezas de  código con muy poco esfuerzo.

    Pueden encontrar información de referencia aquí.

     

Page 1 of 1 (4 items)