La masa, el ladrillo, la bota, el bocadillo...

es una diyuntiva como tu dices..pero también esta muy de moda el tema de los inyector. buen post!

Yo soy mas partidario de usar funciones virtuales, creo que son mas flexibles y le das al desarrollador de la clase heredada mas independencia de la clase base, ya que, probáblemente, no deba tener acceso al funcionamiento interno de la clase base.

Además Manolo está hablando de realizar acciones después de insertar, entonces recomiendo virtualizar:

public class ClaseBasica

   {

       public virtual void insert()

       { }

   }

   public class ClaseHeredada:ClaseBasica

   {

       public override void insert()

       {

           base.function();

           //Añadir funcionalidad despues de insertar

       }

   }

También creo que es una estructura mas legible y de mayopr calidad.

Miguel tu código tiene un pequeño problema y es la misma que dice Rodrigo en el sentido de que te permite sobreescribir el funcionamiento de la clase base. Deja en manos de la clase heredada hacer la llamada a la clase base y si no lo hace, rompe la funcionalidad heredada: la de insert(). Para solucionar este tema existe un patrón que se llama plantilla (template):

public class ClaseBasica

  {

      public virtual DespuesDeInsert() {};

      public virtual void insert()

      {

             // Hacer cosas de Insert

             DespuesDeInsert();

      }

  }

  public class ClaseHeredada:ClaseBasica

  {

      public override void DespuesDeInsert()

      {

           // haz lo que quieras

      }

  }

De esta forma, aseguras que la clase hija no modifica el comportamiento original de la clase padre y a la vez permite añadir funcionamiento adicional. Si todas las clases heredadas necesitan implementar DespuesDeInsert por fuerza, entonces hazlo abstracto.

Por otra parte, Rodrigo, no creo que IoC resuelva algo en esta situación. IoC es para invertir el control, no para inyectar comportamiento. Y desde luego no se debe usar porque algo esté de moda. Y mucho menos si no es la solución apropiada.

Ambas soluciones son buenas y cumplen su objetivo, pero creo que hay algo que no estamos teniendo en cuenta,

¿que seria lo mas "natural" para el programador que escriba el formulario derivado?

Personalmente creo que en este tipo de situaciones, lo natural para un desarrollador seria buscar evento y suscribirse a él.

Por lo tanto en mi caso preferiria un evento.

DevJoke,

"¿que seria lo mas "natural" para el programador que escriba el formulario derivado?"

¿Y porque es un evento? Independientemente, el evento es un procedimiento que se ejecuta en respuesta a una acción, la de inserción. Al final y al cabo, el método de implementarlo es usando el patrón plantilla, pero sin la necesidad de introducir un evento.

Justamente tener formularios y controles con 20.000 eventos es lo que hará que el código sea ilegible.

En este caso particular coincido con el comentario anonimo de utilizar el patron template.

Si estoy heredando de un clase, pienso que la manera de añadir comportamiento a las operaciones base es utilizando el patron template.

Otra cosa es si quiero cambiar el comportamiento de un objeto desde fuera, en ese caso si que veo mejor el uso de eventos. Por ejemplo en el caso tipico del onclick, al boton instanciado le puedo decir que hacer cuando se produzca el onlclick suscribiendome al evento.

Saludos.

Según entiendo el problema, tenemos un formulario base que realiza inserciones, y en casos particulares queremos hacer otro tipo de operaciones.

Es aqui donde esta el problema, en la naturaleza de esas "otras operaciones".

Por ejemplo, si lo que queremos hacer despues de la inserción es actualizar un grid de datos para que muestre en pantalla los nuevos registros - para mi - lo "natural" seria un evento "AfterInsert", en el que refrescar los datos. Por supuesto, crear el método virtual y sobreescribirlo es otra solución igual de válida , pero en este caso creo que menos "intuitiva".

Otro escenario totalmente distinto seria que queramos modificar el comportamiento del insert, por ejemplo para hacer una segunda insercion en otra tabla. En este caso seria mejor un método virtual, que nos permitirá envolver las dos operaciones en una única transacción.

Con esto llegamos a la recomendación de MicroSoft, tener el evento y la posibilidad de sobreescribir el método que lo invoca.

Sobre lo que dice el comentarios anonimo :

"Justamente tener formularios y controles con 20.000 eventos es lo que hará que el código sea ilegible."

Ese codigo resultará igual de complejo e ilegible en los dos casos.

Según yo tengo entendido, el proposito del post es este problema:

"Otro escenario totalmente distinto seria que queramos modificar el comportamiento del insert, por ejemplo para hacer una segunda insercion en otra tabla. En este caso seria mejor un método virtual, que nos permitirá envolver las dos operaciones en una única transacción"

y la solución ofrecida originalmente (la que tu llamas hacer un método virtual) tiene el defecto de que si se opta por hacer un eso, se puede cambiar la funcionalidad del padre y no es lo que el amigo de Rodrigo preguntó originalmente. Preguntó como puede extenderlo, hacer una serie de cosas adicionales.

Siempre relacione los eventos y delegados con los triggers de las bases de datos por eso mismo, pense que para la realizar una acción concreta despues de una inserción, lo mas logico seria realizar un evento post similar a los un triger insert, ya que me parecia lo mas natural, ademas no habia código compartido por otros formularios, asi que pense que el metodo virtual seria menos natural, ya que todos los formularios podrian acceder a el y no tendria nada de código, pero claro "el muy cab... de mi compañero, como siempre llevandome la contraria, empezo a decir que no tenia razón, que lo más lógico seria utilizar un metodo virtual y bla, bla...", como en la mayoria de las ocasiones no nos ponemos deacuerdo y con el fin de terminar la discusión le dije: Bien, preguntale a Rodrigo, y nos ceñiremos a lo que opine el, que lo sabe mejor que nosotros...

Para colmo el tambien se lo envio a Unai que respondio rápidamente diciendo que para el lo mas adecuado era un metodo virtual, lo que tuve que aguantar hasta que recibio tu correo al dia siguiente...

En fin la culpa la tengo yo, por no saber dar ordenes, he de comprarme una vara de avellano...

En fin, se que tengo que tener paciencia con el, el pobre tuvo la mala suerte de nacer en "Solares", una zona de Cantabria, donde solo habitaban 4 membrillos que luego fueron conquistados por los Romanos, y ahora mirarle, discutiendo sobre delegados y metodos virtuales, cualquier dia le tengo que aguantar dando una charla sobre "Cobol.net", la verdad es que el tio, tiene merito....

Por aclarar algo el problema, queriamos  implementar funcionalidad para controlar procesos que se produzcan antes y despues de insertar, eliminar, duplicar y  modificar registros en nuestros formularios, siempre serían acciones que se realizan antes o despues de estos procesos de forma similar a los triggers Insert, Update, y Delete, pense que un evento y delegado seria los mas adecuado para implementar estas caracteristicas, ya que van a utilizar en determinados casos y por supuesto no aprovechan ningún código en común, como bien dice Rodrigo, la solución mas adecuada es aplicar el pàtrón de .net, con lo que tienes que implementar tambien una función virtual, "es curioso que el fxcop no avise de esto", con lo cual utilizamos lo mejor de ambos metodos, un paso mas alla que conjuga lo mejor de ambas propuestas. Muchas gracias Rodrigo.

Lo se, y te lo agradezco, pero el elemento este, le ha mandado la consulta con hasta el mismisimo Bill Gates, que me acaba de llamar y me dice que por favor, que le dejemos empaz, que usemos los putos delegados de los cojones, que para esos los inventaron, y que han colapsado los servidores de correo con la misma pregunta a todos los desarrolladores de Microsoft, asi que como veo que esto se va a hacer público, que mas da.... Gracias de nuevo.

Gran post Rodrigo, me ha gustado mucho esta discusión.

Saludos titán.

Queridisimo jefe:

Tenia pensado en hacerlo y que mi compañero me lleva la contraria difiere de: "Tienes que hacer todas estas cosas y hazlo como creas conveniente", una vez echo y estando funcionando, (esta parte culpa mira), te digo mira como he echo esto ¿que te parece...? y va y se te ocurre "no me gusta como lo tienes echo, mejor los eventos"... y luego me dices que yo discuto... Jefes no puedes vivir sin ellos pero con ellos tampoco...

Como te he recordado muchas veces, mas vale ser de Solares que por lo menos tenemos un agua no contaminada, que no desearlo... el pobrecito intento venir a Solares y no le dejaron cruzar la frontera y se tuvo que ir a Torrelavega... en fin que ya empezamos a estar seniles, hacerse mayor es lo que tiene...

PD. Me ha comentado Bill que te dediques a matar al Zorro ese...

Los eventos nos brindan la potencia de "acoplar" una capa adicional a lo que ya tengamos hecho, esto creo que lo dice todo.

No sino me mosqueo... esta bien eso de discutir, por lo menos se te hace mas ameno la jornada al ritmo del tong tong del tambor (como en los barcos de remos) je je je... y te escucha (aunque no te haga caso)...  Pero bueno como se suele decir al jefe ni agua y en desierto polvorones... lo mejor seria tener un jefe que sea del departamento de sistemas (lo siento por los de sistemas tengo grandisimas experiencias)

Excelente respuesta. Obviamente, qué es mejor en cada caso dependerá (verbigracia) del caso, y por eso el patrón de implementación de diseño que propone (y utiliza siempre) MS permite que utilicemos lo más conveniente al caso.

Para una clase que quiere "enterarse" de que el formulario graba (pero sin modificar el proceso, a lo sumo cancelarlo) será mejor un evento.

Para una clase derivada que quiera modificar o extenderlo, la sobreescritura es lo más claro. Piensen qué difícil de leer sería el caso de una clase derivada que escucha el evento Grabar de la base, lo cancela y graba algo completamente diferente.