ASP.NET 4.0: Jueves 25 de Noviembre 2010 de 12:00 a 14:00 en la Universidad de Lleida
Experiencias de Usuario con Silverlight: Juves 17 de Febrero 2011 de 10:30 a 11:30 en la Universidad de Lleida
HTML5,jQuery; una aplicación: Juves 10 de Marzo 2011 de 12:00 a 14:00 en la Universidad de Lleida
Windows Phone 7, desarrolla!: Juves 14 de Abril 2011 de 12:00 a 14:00 en la Universidad de Lleida
Un articulo muy interesante, esperamos el segundo...
Gracias Marcelo! Prometo una segunda entrega práctica muy pronto :)
Frances, en principio no es muy buena idea recurrir a las llamadas a BeginInvoke y EndInvoke de los delegados puesto que estos incurren en uso de plataforma de Remoting y el rendimiento podría verse afectado. Suele ser mejor construirse el propio patrón de asincronía en .NET..
Saludos
Unai
¡Hola Unai!
Pues no tenía conocimiento de que usar esto así tuviera penalización en el rendimiento. Sobre lo que comentas de implementar un propio patrón de asíncrona en .NET, me parece interesante, pero debería haber alguna forma más práctica de hacer lo que propongo en el ejemplo usando únicamente el Framework de .NET sin penalizar el rendimiento.
¿Alguna propuesta?
.NET solamente propone el patrón y te da las bases para que tu lo implementes, BeginInvoke y EndInvoke es una implementación del patrón, pero no quita que tu puedas hacer la tuya, de hecho como comenté suele ser lo recomendable
Hola Francesc, estupendo articulo el tuyo enhorabuena.
Solamente comentar una pequeña cosa, cuando comentas en tú artículo de usar [MethodImpl(MethodImplOptions.Synchronized)] tienes que tener en cuenta que es lo mismo que llamar a Monitor.Enter(this) o lock(this) y fíjate que utilizo this como objeto de bloqueo porque es justamente lo que hace ese atributo, si el método fuera estático sería Monitor.Enter(typeof(MiTipo)) o lock(typeof(MiTipo) lo que es algo mucho peor.
Lo ideal para estos casos es utiliza una varible de tipo object y utilizar esa variable como objeto de bloqueo, intentando que el tiempo que el método se pasa bloqueado sea el mínimo posible para aumentar así el tiempo de respuesta del sistema.
Yo lo hubiera implementado con ThreadPool.QueueWorkItem para hacerlo asíncrono.
Saludos. Luis.
Gracias por las aportaciones a los dos! Ambas muy interesantes!
Saludos.Francesc.
Creo que este blog promete, con comentarios de tantos cracks..
Muy bueno el articul y muy buenos comentarios.
Suele ser mejor construirse el propio patrón de asincronía en .NET.., como se haria eso?
Aquí tienes un ejemplo de implementación de IAsyncResult para hacer el patron de asincronía de .NET y de paso, también usando ThreadPool.QueueUserWorkItem
blogs.msdn.com/.../AGenericIAsyncResultImplementation.aspx
Gracias Unai!
De todas formas estoy preparando un post con una implementación que uso parecida a la de MSDN para que se comprenda mejor el porqué de implementar IAsyncResult.
francesc
este es un articulo muy bno
"Cómo la idea de SCSF es crear la aplicación por módulos, básicamente para que equipos grandes de desarrollo puedan trabajar de forma simultánea sobre el mismo proyecto".
Interesante, aunque jamás me atreviría a añadir código de más para poder meter más gente en un proyecto :-P
Hola Jesús,
Yo no lo veo así :), no se trata de meter más código para tener más gente en el proyecto, si no que se trata de usar una arquitectura completamente estable y muy bien testeada (igual que la Enterprise Library) para minimizar problemas comunes que se pueden dar al desarrollar aplicaciones windows y así terminar con un mayor éxito la aplicación.
Además también tiene otras ventajas, como poder cambiar la UI a Silverlight o WPF sin tocar ni una línea de código.
Salu2
te parecerá una pregunta tonta... y quizá lo sea xD pero como haces para que el código se vea en colores en geeks?
Que nivel! Cúando lo intente no me funcionava y me dí cuenta justo ahora que era por el StreamedResponse y claro, pues tiene toda su logica..!
Gracias!
Supongo que otra limitación de usar MTOM sería en casos en que queramos compatibilidad con otras plataformas, o no?
Excelente artículo!!!, un saludo.
Cuando la compatibilidad con otras plataformas es un requisito en tú aplicación y necesitas gestionar ficheros de gran tamaño, MTOM te va a servir.
En WCF quien proporciona la interopelabilidad no es el MessageEncoding si no el tipo de binding que se usa.
Tanto basicHttpBinding cómo WSHttpBinding entre otros tipos són compatibles con cualquier servicio que soporte SOAP 1.1, al fin y al cabo transmite mediante XML pero con un tipo de compresión especial.
Slds!
Gracias Juan!
Oki Francesc, gracias por la info
Muy interesante Francesc. La verdad es que nunca me había planteado enviar los correos desde SQL Server. Un saludo.
Hola Jose!
No te acostarás sin saber una cosa más ;) La verdad es que según cómo se haga incluso puede ser mejor que lo haga el SQL server que la propia aplicación. En el @recipients puedes poner todas las direcciones de @mail que quiees enviar y por lo tanto ya no sería necesario gestionar ese proceso des de la aplicación ¿Que creeís? ¿Es más optimo desde SQL o desde la aplicación?
Francesc, gracias por el ejemplo; pero yo tengo una premisa en mi haber es que la base de datos es para manejar datos, porque cuando comenzamos a jugar con estos procedimientos y empezamos a hacer que la DB haga cosas que son propias del negocio ... pues acoplamos y complicamos los sistemas.
Una vez más, no es crítica, sino una opinión. ¿podés contarnos en que tipo de escenarios reales necesitas que la DB envie correo para tenerlos como referencia?
Hola Bruno!
Cómo ya sabrás el correo usado des de base de datos permite realizar envíos de forma asíncrona lo cúal nos resulta útil cúando un proceso es llamado des de la aplicación, web en este caso, debe enviar miles de emails para hacer una notificación y puede durar, horas e incluso días.
Suponte que el director de la empresa "x" solicita a finales de año a la aplicación web que usa un resumen a enviar a todos los accionistas de la actividad del año en el que estan.
Existe un stored procedure que debe realizar calculos y resumenes con los datos para cada accionista y al final llamar al procedimiento msdb.dbo.sp_send_dbmail para enviar cada uno de los resumenes a cada uno de los accionsitas en un formato específico, html.
También me sirve para que SQL Server me notifique de un fallo en la copia de seguridad, una importación de datos costosa...
¿Cómo lo harías tú?
Gracias por tu opinión :)
Saludos!!
El envío de correo desde nuestra aplicación o desde la base de datos dependerá de nuestra logica de la aplicación o nuestra forma de trabajar. Y a veces la elección de una o otra es tan valida como la otra.
Supongamos que tenemos una aplicación en el cual hay unos procesos que pasan por estados, y dependiendo de los estados tienen que enviar correos a varias personas o grupos de personas de la empresa para realizar el seguimiento del proceso.
En este caso, es mucho mas fácil mandar los correos desde la base de datos, ya que cuando realizamos el cambio de estado en la base de datos podemos enviar los correos en el mismo proceso, que tener que cambiar el estado y luego recuperar los datos de los usuarios a los que se tiene que enviar el correo y realizar los envios desde la aplicación.
En cambio habra otras aplicaciones, en las que el envío de correo sea una cosa puntual y lo podamos hacer desde la aplicación, por ejemplo, una aplicación en la que el usuario realiza un test y luego se envía el correo con la nota. En este caso el envío es más puntual.
En conclusión, el envío del correo desde la aplicación o desde la base de datos depende de nuestros gustos y nuestras necesidades de la aplicación.
Si tenemos que realizar varias operaciones en base de datos (y despues informar a varios usuarios) antes del envío de los correos, realizar procesos automaticos, devolución de conjunto de datos sin procesamiento alguno aconsejo poder aprovechar la oportunidad que nos da Sql Server para el envío de los correos desde la base de datos, en caso contrario realizar los envios de correos desde la aplicación.
@Francesc y @Jose, muchas gracias por las explicaciones. Yo principalmente dejo la DB para tareas de DB, porque cuando existe un SP que tiene muchos cálculos y realiza procesos muy pesados, eso significa que seguramente este SP tiene muchas lineas y tiene logica de negocio dentro de la base de datos. Por más que digan lo que digan, picar logica de negocio en T-SQL suele ser un infierno; y cuando veo SPs que tienen miles de líneas .. pues me da miedo. Prefiero hacer un proceso un poco más pesado y dejar separado los limites de negocio, de aplicacion y de datos ... pero claro, también entiendo que existen muchas casuísticas, muchos proyectos diferentes, y que no hay una solución única para todo. :D
@Bruno, no estoy muy deacuerdo con la afirmación en la que dices 'empezamos a hacer que la DB haga cosas que son propias del negocio', creo que esto esta muy bien para evitar problemas, pero la realidad es que una base de datos hace muchas mas cosas que pueden ser propias de la capa de negocios, de hecho en las últimas versiones incluso de expositora de servicios web, dts y un largo etc. Hay ciertas funciones que en la base de datos nos proporcionan muchas ventajas, por ejemplo notificaciones automáticas cuando modificamos cierto valor en una tabla, esto es muy dificil de implementar si la tabla es accedida por sistemas diferentes, imagina que tienes un cliente en Access, comercio electronico, hojas excel y desde ellas cambias algun valor..., ¿ Como implementas esta funcionalidad en capa de negocios ?, seguramente se pueda, pero el coste sera mucho mayor.
Ciertos aspectos de la base de datos nos facilitan el desarrollo de determinadas funciones. Aunque entiendo tu punto de vista, en el que la capa de negocios deberia encargarse de todos estos apartados, lo cierto es que en mi opinión algunas de estas funciones pueden presentar mas ventajas que incovenientes, pero que han de usarse con precaución porque tambien son fruto de muchos errores.
Un Saludo.
Hey @Juan que bueno leerte por aquí. Pues yo trato de ser siempre SOA compliant, es decir publicar mi lógica por servicios y luego consumirla desde servicios !!!
Se que es mucho más costoso en algunas ocasiones que "abrir la base de datos a los usuarios", pero es que mis experiencias con este tipo de escenarios han sido realmente funestas; tanto en mantenimiento (ya comentaba lo feo que es tener SPs de miles de lineas de largo) como a nivel tecnología.
Por poner un ejemplo, tu bien comentas que hoy las DBs tienen muchas más funciones que las de un simple CRUD; por ejemplo los EndPoints (webservices exponiendo funciones o SPs) o la capacidad de generar ensamplados .Net e incorporarlos a la base de datos. Pues esta combinación no sabes los dolores de cabeza que nos trajo en un proyecto hace un tiempo, porque claro, nadie pensó en lo complicado que es el despliegue de estos ensamblados en las bases de datos porque ademas de no ser un proceso trivial, es necesario desplegar respetando el orden de referencias y tal vez para cambiar el ensamblado X necesites hacere 20 pasos !!!. Ni en que los EndPoints solo eran compatibles con Html 1.1 (eso no se sigue siendo así), etc y otro monton de problemas más; que a la larga hacían el mantenimiento de la aplicación un infierno ...
Es por eso que en mi caso, y siempre que se pueda, servicios desacopladitos, con todas sus pruebas por debajo; pero claro la realidad no siempre lo permite.
Saludetes :D
Hola Bruno, estoy completamente deacuerdo con lo que comentas, ensamblados .net, procedimientos almacenados complejos y otros aspectos pueden suponer muchos dolores de cabeza, pero creo que ciertas capacidades pueden llegar a ser muy útiles en ciertos entornos (por supuesto extremando las precauciones). Nosotros utilizamos un sistema de notificaciones automatico desde Sql server basado en el servidor de correo, de forma que cada vez que se realiza un impagado independientemente que este se realice a traves del sistema de comercio electronico, programa winforms del cliente, o a traves de una simple hoja de cálculo excel o access envie una notificación de forma automatica al responsable financiero, agente y comercial, este tipo de servicios nos han funcionado muy bien, incluso cuando hemos actualizado a la versión 2005 y 2008, tanto que hemos extendido estas notificaciones automáticas a través de este método, creo recordar que en el sistema de gestión actual tenemos mas de 60 tipos diferentes.
Estoy deacuerdo en que hacerlo a traves de SOA es una excelente solución, pero tambien creas dependencia con IIS y tienes mayor complejidad ya que en ciertos entornos acceder a través de SOA con clientes como excel o access puede complejo.
En mi caso, las notificaciones automáticas a traves de la base de datos pueden ser una buena solución en determinados entornos.
A ver si coincidimos en alguna evento y charlamos un rato.
Un saludo.
Muchachos(que algun dia fueron XD) lean esta entrada de un blog de un amigo mío respecto al punto de discusión.Gracias
geeks.ms/.../159080.aspx
hola como estas me prodrias ayudar como publicar un servidor web en sql server 2008 te lo agradecere mucho
genial, me ha servido perfectamente!!!
Hola que tal, la verdad me parecio muy interesante pero me gustaria crear el profile mediante codigo, mencionaste inicialmente que se podia y te agradeceria si me podrias enviar algo te dejo mi email: andy.r3@gmail.com
Gracias..
Hola,
Me parecio muy bueno este blog, al igual que Andy, me gustaría tener el código para la creación del perfil, podrías enviarmelo, también me gustaría poreguntarte, ¿La version express te permite el envío de correo electronico?
Que se puede no significa que sea adecuado utilizarlo, más bien la opción por defecto es NO usar nunca esta característica, por eso viene desactivada :-)
Un saludo,
Hola!!
Que exista, no significa que todos lo utilizen o lo utilizemos, cierto :) En mi opinión, y no cómo proceso común de desarrollo y creación de procedimientos almacenados, utilizar CLR puede ser tener sus ventajas.
La mejor de todas es que podemos utilizar la potencua de .NET dentro de SQL mejorando los limites que puede tener T-SQL, como por ejemplo las tareas de encriptación dónde si uso este tipo de característica :)
En todo caso y cómo siempre, hay que evaluar para que y porque se quiere usar.
Un saludo!!
Buen post ... pero PELIGROSO !!! Después de sufrir en un proyecto donde una serie de iluminados decidieron crear SQLCLRs a cascoporro, les cuento un par de detalles a tener en cuenta:
- el despliegue es un infierno, las dependencias me hacen acordar al infierno del DLL HELL
- olvidate de depurar
- 2 semanas trabajando con SQLCLR y el concepto de prueba unitaria se te olvida
- no es 100% .Net !!! existen limites documentados para acciones "tontas" como las funciones recursivas
no me acuerdo más, pero para más informacion, comentar que nos costó sacar toda la mi##@#da de los SQLCLRs casi 6 meses en un proyecto, a 7 personas, pa un proyecto pa toda europa.
Antes d este proyecto me parecia una buena opción, hoy no puedo encontrar un escenario en el que utilice SQLCLR sin encontrarle una pega.
Salu2 y no te ofendas Francesc, lo mio fue una quemazon por la mala experiencia :D
Hola Bruno!!!
Para nada ;) Sé lo que son las malas experiencias con estos temas de programación!
Al turrón, el uso indebido de cualquier cosa, siempre es peligroso y usar esto en todos los lados, más. Ya te digo, se debe de analizar el caso y para que se quiere usar, yo únicamente lo uso para encriptación de datos, el resto, .net ;)
Un saludo y nos vemos pronto por el sud!
Estoy de acuerdo contigo, pero todos deben de saber que todas las herramientas no son generica o aplicada para todos los casos usted elije en que le pude dar utilidad.
Gracias por tu gran aporte. Favor de enviarme el código crear el profile mediante
Por fa tu crees que podrias enviarme todo lo que has explicado en tu post pero en codigo, yo tmb he hecho la configuracion del envio de correo mediante el wizard, pero necesito tenerlo en codigo.
Gracias
Agregado a mis favoritos, seguro que aprendo mucho de tus posts. Saludos!
Gracias Ivan!! ;)