edited

If you want to go through callbacks, so that the code you have put compiles for you, you must do something similar to this:

In the form that calls it:

private void tsbPersonalInasistencias(object sender, EventArgs event)
{
    var frm = new frmPersonalListado(x => {
        var frm2 = new frmCrudPersonal(x); // <-- nota que usamos el parametro de la lambda (x)
        frm2.ShowDialog(this)
    });
    frm.ShowDialog(this);
}

In frmPersonalListing:

private Action<Personal> _func;

public frmPersonalListado(Action<Personal> nextForm)
{
    _func = nextForm;
}

private void btnSeleccionar_Click(object sender, EventArgs event)
{
    var personal = ObtenerPersonalSeleccionado();
    _func(personal); // El 'x' de la lambda de arriba se convierte en "personal"
}

That said, this option is neither better nor easier to maintain than the other. All you're doing is delegating the code to a callback, but in the end you write the same code as if you did it by hand.

As I say, there are a thousand ways to do it: you could pass the type and use the Activatorto create the instance, or directly pass the following type in a form generic (although you would lose the WinForms designer unless you use some tricks). Your target forms could also implement an interface that had some function EligePersonalor something similar, and pass the interface type to the staff selector (such as dependency injection, but not automatic, since it is variable according to parameters).

In any case, I think you are starting the house from the roof: if your idea is to have maintainable and manageable code, start by stopping writing business logic in the form and start using some design pattern (the one that is most comfortable for you). , although MVP is the one that is usually applied to WinForms, you can also use MVVM or MVC)... and if you don't want to use any of these, you can make your own, but write the logic of what the functions do in the events themselves (apart from modifying the view itself) is already unmaintainable, and you should start there.

What you want to do you can move around, but in the end, you have to somehow write the code (or the type of form at least) that you need. Either in Actions, either through interfaces, or by passing types and creating them with the Activator, or by injecting dependencies.

THAT is not the maintainability issue.

And the most logical thing in your case (be it a form, or 100, it doesn't matter), is that if a form needs a selected person, it has two options: you call it with that person (through a function, in the constructor, wherever you want) , or else you call him without that person: in that case, that form (and not the "caller") should be the one in charge of taking you out of the personnel selection window.

That is what is "conceptually" logical, and not the other.

old question

No longer applicable after question edit

Man, I don't really understand the question very well, but if the idea is (if I haven't misunderstood it), that when you select an option, a form first opens letting you choose the staff (this is common regardless of the option you choose ), and then the form opens with the data of the person you have chosen...

Well, there are a thousand ways to implement it, but seeing that you are using it ShowDialogfor everything and that the application follows a fixed flow blocking the rest...

So I would reverse the order of actions, and have a "staff" selector in a helper class.

Following your example:

frmPersonalListado.cs

// Pasamos el constructor a privado:
private frmPersonalListado()
{
    InitializeComponent();
    _personalNegocio = new PersonalNegocio();
    _inasistenciaNegocio = new Lazy<InasistenciaNegocio>();
}

private Aplicacion.Entidades.Personal _personaSeleccionada = null;

public static Aplicacion.Entidades.Personal SeleccionaPersonal()
{
  using(var frm = new frmPersonalListado())
  {
    var dr = frm.ShowDialog(); // podemos pasar el owner como parametro si es importante
    if(dr == DialogResult.Ok)
      return frm._personaSeleccionada;
    return null;
  }
}

private void tsbVerPersonal_Click(object sender, EventArgs e)
{
  _personalSeleccionada = lvPersonal.SelectedItems[0].Tag as Aplicacion.Entidades.Personal;
  this.DialogResult = DialogResult.OK;
}

And in the main form, where before you did the ShowDialogde frmPersonalListado, now you do:

private void tsmiDatosPersonal_Click(object sender, EventArgs e)
{
    var persona = frmPersonalListado.SeleccionaPersonal();
    if(persona != null)
    {
       using(var frm = new frmPersonalCRUD(ModoFormulario.Ver, persona))
       {
         frm.ShowDialog(this);
       }
    }
}

private void tsmiInasistenciasPersonal_Click(object sender, EventArgs e)
{
    var persona = frmPersonalListado.SeleccionaPersonal();
    if(persona != null)
    {
       using(var frm = new frmElOtroTipoDeFormulario(ModoFormulario.Ver, persona))
       {
         frm.ShowDialog(this);
       }
    }
}

This would be the simplest and "healthiest" way according to what I have understood from the specifications.

If the recruiter is going to be called from other places, it might be worth putting it in each of those forms (in the event Loador similar).

From there, and in terms of maintainability, you can mess with whatever you want... from injecting (making an interface and using DI) the personnel selection form to the target form, to whatever you want. This solution that I give you is very basic but so does the code that you show us.

Disclaimer: I have written the code quickly and without checking it, there are probably syntax errors

If you don't want your project to turn into unmaintainable chaos as soon as it gets a little bigger, you should separate logic from presentation. A good way to achieve this in Windows Forms is to use the Model-View-Presenter pattern . Copied from that link:

Basically this pattern consists of 3 components:

• The view. Comprised of the windows and controls that make up the application's user interface.
• The model. Which is where all the business logic takes place.
• The presenter. It listens for events that occur in the view and executes the necessary actions through the model. You can also access views through interfaces that the view must implement.

Here's an example solution on GitHub built from the example with three forms you show in your question. Below I explain the most significant points of the project.

• First of all we create the classes that represent the model that we want to display/edit in the user interface.

We also include a repository for data, with its corresponding interface:

class PersonaResumida
{
    public string Nombre { get; set; }
    public string Apellido { get; set; }
    public string Dni { get; set; }
}

//Podría heredar de PersonaResumida
class PersonaEnDetalle
{
    public string InformacionAdicional { get; set; }
}

class Inasistencia
{
    public string Motivo { get; set; }
    public DateTime Desde { get; set; }
    public DateTime Hasta { get; set; }
}

interface IRepositorioDePersonal
{
    IEnumerable<PersonaResumida> ObtenerPersonas();
    PersonaEnDetalle ObtenerPersona(string dni);
    IEnumerable<Inasistencia> ObtenerInasistencias(string dni);
}

• Next we create interfaces for the views . These interfaces model the external behavior (the interaction with the rest of the application) of the views.

We also create a base interface with common functionality:

interface IElementoDeUI
{
    void Cerrar();
    event EventHandler CierreSolicitado;
}

interface IListadoDePersonalUI : IElementoDeUI
{
    void EstablecerPersonas(IEnumerable<PersonaResumida> personas);
    event EventHandler<PersonaSeleccionadaEventArgs> PersonaSeleccionada;
}

interface IDatosDePersonalUI : IElementoDeUI
{
    void EstablecerPersona(PersonaEnDetalle persona);
}

interface IInasistenciasDePersonalUI : IElementoDeUI
{
    void EstablecerInasistencias(IEnumerable<Inasistencia> personas);
}

Notice how we have two types of interactions: towards the view (we establish the data to be displayed) and from the view (events generated, in this case, only by the user).

• We create the views (the forms), which implement the interfaces.

Also in this case we create a base class that will implement the common interface:

public partial class FormBase : Form, IElementoDeUI
{
    public event EventHandler CierreSolicitado;

    protected void EmitirCierreSolicitado()
    {
        CierreSolicitado(this, EventArgs.Empty);
    }

    public void Cerrar()
    {
        this.Close();
    }

    //Hay más código, sólo se muestra aquí lo importante
}

public partial class frmListadoDePersonal : FormBase, IListadoDePersonalUI
{
    public event EventHandler<PersonaSeleccionadaEventArgs> PersonaSeleccionada;

    public void EstablecerPersonas(IEnumerable<PersonaResumida> personas)
    {
        gridPersonas.DataSource = personas;
    }

    private void btnCancelar_Click(object sender, EventArgs e)
    {
        EmitirCierreSolicitado();
    }

    private void btnOk_Click(object sender, EventArgs e)
    {
        var dni = (gridPersonas.SelectedRows[0].DataBoundItem as PersonaResumida).Dni;
        PersonaSeleccionada(this, new PersonaSeleccionadaEventArgs {DniSeleccionado = dni});
    }

    //Hay más código, sólo se muestra aquí lo importante
}

//Hay más vistas, omitidas por brevedad

• We need a view factory , which is responsible for generating the form instances from their interface, and some other auxiliary operation with the UI engine.

This would be the factory interface, the example project implementation uses Activator.CreateInstancebut that is now irrelevant:

interface IFactoriaDeUI
{
    T ObtenerInstanciaDe<T>() where T : class, IElementoDeUI;
    void Mostrar<T>(T elementoDeUI) where T : class, IElementoDeUI;
}

• And finally we have the presenter , which is in charge of coordinating the creation, closing and interaction between the views.

A continuación un fragmento del código del presentador. ¡Fíjate que no tiene ninguna dependencia con Windows Forms!

class Presentador
{
    private readonly IVentanaPrincipalUI ventanaPrincipal;
    private readonly IFactoriaDeUI factoriaDeUi;
    private readonly IRepositorioDePersonal repositorioDePersonal;

    private string solicitud; //Tipo string para simplificar, se podría usar un enum

    public Presentador(
        IVentanaPrincipalUI ventanaPrincipal, 
        IFactoriaDeUI factoriaDeUi, 
        IRepositorioDePersonal repositorioDePersonal)
    {
        this.ventanaPrincipal = ventanaPrincipal;
        this.factoriaDeUi = factoriaDeUi;
        this.repositorioDePersonal = repositorioDePersonal;

        ventanaPrincipal.DatosSolicitados += VentanaPrincipal_DatosSolicitados;
        ventanaPrincipal.InasistenciasSolicitadas += VentanaPrincipal_InasistenciasSolicitadas;
    }

    private void VentanaPrincipal_DatosSolicitados(object sender, EventArgs eventArgs)
    {
        solicitud = "datos";
        MostrarListadoDeUsuarios();
    }

    private void VentanaPrincipal_InasistenciasSolicitadas(object sender, EventArgs eventArgs)
    {
        solicitud = "inasistencias";
        MostrarListadoDeUsuarios();
    }

    private void MostrarListadoDeUsuarios()
    {
        var usuarios = repositorioDePersonal.ObtenerPersonas();
        var uiParaListado = factoriaDeUI.ObtenerInstanciaDe<IListadoDePersonalUI>();
        uiParaListado.EstablecerPersonas(usuarios);

        uiParaListado.CierreSolicitado += (sender, args) => { (sender as IElementoDeUI).Cerrar(); };
        uiParaListado.PersonaSeleccionada += UiParaListado_PersonaSeleccionada;

        factoriaDeUi.Mostrar(uiParaListado);
    }

    //UiParaListado_PersonaSeleccionada muestra la vista de detalles
    //o la de inasistencias, dependiendo del valor de "solicitud"
}

Como guinda, así es como se inicia la aplicación. En una aplicación real se usaría algún contenedor de inyección de dependencias:

static void Main()
{
    var formPrincipal = new frmMain();
    var factoriaDeUI = new FactoriaDeUI(formPrincipal);
    var repositorio = new RepositorioDePersonal();
    presentador = new Presentador(formPrincipal, factoriaDeUI, repositorio);

    Application.Run(formPrincipal);
}

Puntos interesantes

• Al ser independiente de la tecnología de interfaz de usuario, el presentador es completamente unit-testable.
• ...y por la misma razón, si quisieras cambiar dicha tecnología en el futuro (por ejemplo, usar WPF) podrías reutilizar el presentador (y también las clases del modelo y los interfaces de las vistas).
• The views themselves may have some internal logic that does not affect the operation of the application as a whole. For example, in the personnel list, the code that is responsible for disabling the "Continue" button if no person is selected can be part of the code-behind of the form. But if you want to unit test for this, you'll need to control it from the presenter. It's your decision.
• As your application grows you will probably need to create a class that handles the business logic and leave the presenter solely for presentation logic .

And basically that's it. I hope this ramble is helpful to you.

I still don't quite understand what you want, but if you want to have a "creator" of forms, it would be good if you implemented a design pattern of the creation category, to separate the form creation logic from the logic that chooses the form that should go on, and in the form creation logic you handle instantiation and stuff. I recommend you read the Factory Method Design pattern , this to ensure code maintainability.

In software design, the Factory Method design pattern consists of using an abstract constructor class (in the style of the Abstract Factory) with a few defined methods and another(s) abstract(s): the one dedicated to the construction of objects of a subtype of a certain type.