Convocatoria para seminarios
ADO.NET/Data Binding c/ Visual Studio 2005/C#
Boadilla del Monte, Madrid
Segunda convocatoria: 24 de junio de 2006
Tercera convocatoria: 1 de julio de 2006
Boadilla del Monte, Madrid
Segunda convocatoria: 24 de junio de 2006
Tercera convocatoria: 1 de julio de 2006
El seminario tratará sobre la implementación de una aplicación con acceso a bases de datos usando Visual Studio 2005 y SQL Server 2005. Aunque el énfasis se pondrá en las técnicas de enlace de datos, mostraremos también como utilizar un servicio Web para recuperar parte de la información utilizada por la aplicación.
- Adaptadores de tablas versus adaptadores de datos.
- Implicaciones para el desarrollo en múltiples capas.
- Clases parciales y personalización de las clases generadas.
- Manejo de transacciones: dos técnicas disponibles.
- Recomendaciones para el diseño de la base de datos.
- Enlace a datos en Windows Forms 2.0.
- Interfaces y clases relacionados con el enlace a datos.
- Enlace a datos con objetos de negocio.
- El control DataGridView y su personalización.
- Validación y control de errores.
- Generación de una interfaz visual para un servicio Web.
Documentación entregada: curso a distancia ADO.NET/C# y notas impresas con actualizaciones y contenidos especiales.
Para información de precios, descuentos, plazas y para reservar plazas, contacte directamente conmigo, a través de la cuenta ian arroba intsight punto com.
Ian Marteens, 2:06 p. m.
16 Comments:
Ian,
Personalmente me interesa mucho el temario que se impartirá en los seminarios pero lo cierto es que, al día de hoy, apenas tengo experiencia de programación en C# y menos en ADO.NET (aunque sí, y bastante, en Delphi6 y ADO).
¿Crees que le sacaría provecho al seminario aun teniendo poquísima experiencia con el VS 2005?
Saludos,
Mikel
De eso mismo se trata. Es más, advierto que se trata de una "clase magistral", que es lo que corresponde al tiempo. Lo que ves (y te llevas como código) es un ejemplo práctico con las explicaciones necesarias. Y controlando ya Delphi 6 y ADO, no creo que vayas a tener problemas: más problemas tienen los que vienen de usar Visual Basic "clásico", el anterior a .NET, porque no tienen punto de comparación alguno con lo nuevo. Del seminario, además, te llevas libro y curso a distancias... y el soporte docente del curso a distancia, por lo que cuando te pongas sobre el asunto tampoco vas a estar solo.
... por supuesto, lo ideal en este caso siempre es más tiempo de clases. Lo que sí te recomiendo es que te apuntes cuando sepas que vas a tener tiempo luego para practicarlo. No te preocupes por las fechas, porque pienso repetir este tipo de seminarios a lo largo del año, mientras siga habiendo demanda.
Es impresionante como las personas cambian de punto de vista u opinion. No es malo pensar diferente, pero si lo es el hecho de defenestrar a una herramienta que ha demostrado por tanto tiempo ser brillante, y lo seguira demostrando con la nueva DevCo. Creo que en algun momento deberas hacer un mea culpa por los diversos comentarios en contra de Delphi que has realizado, cuando..; lo curioso es que no hace mucho tiempo eran totalmente diferentes. Es raro, no?.
Es decir: tú asumes que soy yo quien defenestra a Delphi... y a Borland, aunque utilices elipsis para no mencionar nombres propios (lo haces incluso al escribir como "usuario anónimo"; yo, en cambio, incluso cuando me he quejado en la propia BDN jamás me he escudado tras el "Craven Weasel" para decir lo que tenía que decir).
Tu pones tu fe en DevCo. Yo no soy una persona de fe... y muchísimo menos invierto mi potencial emocional en "cosas", o "compañías". Cuando se trata de las herramientas con las que trabajo, intento ser lo más objetivo posible.
Te extraña que haya un cambio de actitud, y supongo, aunque sólo lo insinuas, que "sospechas" algo. Bien, allá tú con tus sospechas. Es tu derecho. Pero los cambios siempre responden a algo, y en este caso demuestras ser incapaz de ver los cambios técnicos que, independientemente de subjetividades, me han llevado a mi actual postura. O no has prestado atención a todo lo sucedido en el mundo técnico en estos años, o has preferido ignorar conscientemente todos estos cambios.
Bien: es tu derecho.
Mi elección, por el contrario, ha sido mantener bien abiertos los ojos y la mente. Y creo que así puedo ayudar mejor a mis colegas de profesión. Ya te digo: no soy un "hombre de fe".
... e insisto: si llega un día en que Delphi vuelve a ser la mejor opción para cualquier programador, no tendré inconvenientes de ningún tipo para decirlo y reconocerlo, aunque ahora lo vea improbable. Y podré seguir durmiendo por las noches a pierna suelta.
Por el contrario, parece ser que eres tú quien es incapaz de reconocer que Delphi ha dejado de ser la herramienta más potente y adecuada. Quizás deberías practicar zazen, o al menos leer algo sobre lo que significa la impermanencia.
Herodoto decía que es imposible bañarse dos veces en un mismo río. Hay quien se empeña en demostrar lo contrario revolcándose en una charca.
Este tío no sabe lo que ha hecho... ¿En qué se parecen Ian Marteens y Cassius Clay? El bueno de Cassius "Volaba como mariposa y picaba como abeja". Pues Ian se le parece sobretodo en lo de la abeja ;)
Es que la primera vez que te salen con la historia, te preocupa (a ver si es verdad y no me he dado cuenta). La segunda vez, ya sorprende por la insistencia. Y a partir de la tercera, ya aburre.
Lo triste de todo esto es que quien sí lo hizo fatal fue el último "chief scientist" de Borland: el gran Danny Thorpe. Incluso en el momento de irse de Borland mira lo que decía:
I was not snatched away from Borland, and I am not leaving Borland for lack of money. I sought out Google, and I'll be making at Google exactly what I made at Borland, which is nicely comfortable but not excessive. There were other suitors (including the obvious one) but, quite frankly, Google outmaneuvered them. (en el blog de Allen Bauer)
Sin embargo, a pesar del "outmaneuvering", a los dos meses el personaje abandona Google (dice que terminó lo que fue a hacer allí... en dos meses) y aparece en el "obvious suitor", enredando con Windows Live. ¿Y soy yo todavía el pringao que es sospechoso de haberse unido no muy ortodoxamente a las huestes del mal? Venga ya... Lo que pasa es que la gente es muy inconsistente (por decirlo finamente).
Un lenguaje con reflexión con una versión beta que asigna sqls a variables, posibilidad de multiplataforma y cuya curva de aprendizaje es mejor para los que vienen de Delphi que los de VB 6.
¿Que más ponemos en la carta a los reyes? ¿Debe ser malo por ser de Microsoft?
Despues de lo que le has dado al VB te has ganado la consideración de objetivo en tus análisis.
¿Habéis visto ya que han cambiado el nombre de WinFx a .NET Framework 3.0? Eso es bueno: quiere decir que las cosas ya empiezan a moverse al ritmo que debían. De todos modos no tengo muy claro que pueden tener todo lo relacionado con LINQ para cuando salga Windows Vista. No por el lenguaje de consulta en sí, porque esa parte ya está trabajada, sino por la presunta integración de recursos en la línea de ObjectSpaces.
parece que a lo lejos se escucha un "ECO" (ObjectSpaces... ObjectSpaces...
ObjectSpaces...)
;)
La "idea" es muy parecida: la única diferencia es que .NET, con un sistema de reflexión mucho más completo que el de Java, podría aportar algo nuevo... aunque no estoy convencido. Y muy probablemente, Heljsberg tampoco. Es más, tengo la impresión de que LINQ es la forma que se le ocurrió de parar lo que se nos venía encima y mejorarlo un poco. Sigo diciendo lo mismo: no hay ventaja alguna en pasar un TCliente de una máquina a otra... en primer lugar, porque si mueves la información con ese nivel de granularidad, te salen canas. La clase "interesante" siempre sería List[TCliente] (el puñetero blogger rechaza los angulares). La orientación a objetos, o más bien, las "interfaces estrechas con mantenimiento del estado", no funcionan bien cuando hay que cruzar fronteras entre sistemas.
... si me refería puntualmente al Enterprise Core Object de Borland (DevCo o como quiera que se llame) que era algo de lo que en principio carecía Microsoft. Bueno, ahora está ObjectSpaces pero por lo poco que entiendo es más o menos lo mismo.
Java tiene Hibernate y algún otro y bueno, se podría decir que también NHibenate para .net
El tema principal me parece, según mi humilde opinión, está en que de alguna forma se solucione el problema de "impedance mismatch" al que se produce al programar en un lenguaje orientado a objetos y "persistir" estos objetos en base de datos relacionales.
Ya sea que se use un ORM o un OPF siempre se producirá una "controversía filosófica" sobre este tema.
Bueno, da para largo, hasta inclusive capaz que se merezca otro hilo de discusión.
:P
El problema es que ObjectSpaces, "como tal", parece haber sido parado dentro de la propia Microsoft. Esto es una apreciación subjetiva mía, no un chivatazo desde dentro. Pero mira la evidencia para que veas por qué lo digo:
1- ObjectSpaces se anunciaba desde hacía mucho tiempo como una de las novedades que iban a estar en .NET 2.0. Incluso hay siete páginas y media (décimas más o menos) dedicadas a ObS en "A first look at ADO.NET and System.Xml v.2.0", de Addison-Wesley. Aunque este libro no es "Microsoft Press", Addison-Wesley publica con la bendición de MS: recordemos que muchos de los libros de referencia sobre C#, el CLR... aparecen en AW, no en MS Press.
2- Había un proyecto paralelo del "equipo de lenguajes": el C Omega. Aparentemente, no se cruzaban.
3- De repente, ObS comienza a parpadear. Se supone que está más o menos completo y funcionando, pero no entra en la beta 1 de Whidbey. Se especula que va a aparecer como parte de SQL Server 2005, pero en la práctica, cada vez se habla menos del asunto.
4- Aparición oficial de .NET 2.0. Ni rastro de ObS.
5- Espectacularmente, C Omega reaparece transformado en LINQ. Pero, ¡ojo!, no son cosas idénticas. C Omega, por ejemplo, incluye una especie de stream basada en lazy evaluation que no aparece en LINQ por ninguna parte, mientras que hay características en LINQ que llevan la clara marca del equipo que diseña C# 1.0 (el vínculo estrecho entre construcciones sintáticas y tipos de interfaz, como el que existe entre foreach e IEnumerable, o entre using e IDisposable).
6- El responsable de ObS reconoce que, con LINQ, ObS deja de tener sentido, tal y como estaba planteado. Sugiere, o eso entiendo, que los resultados de ObS van a incorporarse a LINQ. No tengo el enlace a mano, por desgracia.
Mi conclusión muy personal y quizás equivocada es que "alguien ha tomado cartas en el asunto". Hejlsberg ha expresado públicamente sus recelos hacia este tipo de cosas en varias ocasiones (en www.artima.com hay una entrevista en ocho entregas, y en una de las entregas habla del asunto; no tengo la URL a mano tampoco). Por lo tanto, es muy probable que se hayan dado una segunda oportunidad para replantearse el asunto y ver cómo mejorar sus posibilidades.
Esto, por supuesto, no es una explicación sobre por qué recelo de ObS, ECO, etc, etc, pues como dices, eso da, no sólo para un post, sino incluso para un libro. Sí, efectivamente, el "impedance mismatch" es algo que he venido escuchando (y sufriendo) desde que iba al cole... pero es que se trata de un problema "visible" y fácilmente identificable, y puede ser en realidad un síntoma más que una causa.
Una pregunta como pista: ¿por qué no han triunfado masivamente las bb.dd. orientadas a objetos sobre las bb.dd. relacionales? Mi opinión: porque el concepto de identidad, que es central en la OOP, casa muy mal con el desarrollo en red, que se lleva mejor con copias transparentes y con modelos basados en valores, como el modelo relacional. El esfuerzo necesario para mantener la "identidad" en una red es enorme, y ese es uno de los argumentos de A.H. en la entrevista en artima.com que antes mencionaba. Si no mantienes la identidad, en cambio, te encuentras, como mínimo, en el punto de partida, con el mismo problema que con una bb.dd. relacional... y puede que peor, porque el lenguaje te inducirá engañosamente a creer que tu "copia" es la "verdadera". Y aquí vuelvo a lo que dije en el comentario anterior: la POO se pega un tortazo cuando debe cruzar fronteras de sistemas.
(voy a dividir este comentario en dos)
Esto que voy a recomendar, cogedlo "con pinzas":
Quienes podáis daros el lujo de gastar 40 dólares en un libro técnico al que no le vais a dar una aplicación práctica, intentad conseguir "Transactional COM+: Building Scalable Applications", de Tim Ewald, publicado por Addison-Wesley. Digo que es un "lujo" porque, evidentemente, en cuanto salga Windows Vista con su WFC, COM+ comenzará a languidecer en beneficio de WFC, antes llamado Indigo. Incluso quienes mantengan sistemas basados en Windows 2003, poco uso le darán, pues el libro utiliza Visual C++ 6.0 y mucha ATL.
Pero los primeros capítulos, los que presentan y explican cuál es la "pregunta" para la que COM+ era la "respuesta", son reveladores. Tim Ewald es de la banda de Don Box y sus secuaces, y estas ideas se han incorporado también dentro de Indigo, y están muy relacionadas con el concepto de Service Oriented Applications que empieza a despegar ahora. Este es un libro que me hizo replantearme unos cuantos conceptos. El escritor no es un teórico de la informática, advierto, por lo que no esperéis frases enmarcadas listas para lanzar a la cabeza del adversario durante una discusión.
Ahora se empieza a aclarar un poco más el panorama, al menos para mí.
http://www.theserverside.net/
news/thread.tss?thread_id=41055
Se dispondrá entonces de lo siguiente:
LINQ to ADO.NET, which includes:
LINQ to DataSet
LINQ to Entities
LINQ to SQL (formerly DLinq)
LINQ support for other data types include:
LINQ to XML (formerly XLinq)
LINQ to Objects
Finalmente, ¿solucionará esto el "desacople por impedancia"?
Bye.
No lo creo (lo de que resuelva el impedance mismatch del todo), pero sí tendrá una consecuencia: hará más fácil de programar y mantener aplicaciones basadas en objetos de negocio. Por eso no hubo una Cara Oculta de C# 2.0: el cambio más gordo (o la ampliación, porque los datasets seguirán siendo mejores en muchas situaciones) viene ahora.
Si resuelves del todo el "impedance mismatch" en beneficio de la POO, te ves en un problema: los objetos con identidad son problemáticos para programar en red. Claro, puedes olvidarte de la identidad... pero eso ya es una "concesión". Imagina, por ejemplo, que tu base de datos tiene un objeto singleton (ya no vamos a pensar en tablas: estamos en una base de datos OO de verdad). Para que el ejemplo tenga sentido, digamos que no es un objeto inmutable. ¿Con qué te encuentras? Con que la comunicación entre fronteras de equipo es la clásica entre objetos. Pues bien: problema. Porque la POO consume demasiado ancho de banda. Esto último es una especie de lema (en el sentido matemático): hay que demostrarlo para que el intento de "teorema" sea válido. Pero creo que es evidente, ¿o no...?
Publicar un comentario
<< Home