Buena manera de definir un método

Question

¿Cuál es la mejor buena manera de / para implementar llamadas a métodos.

Para por ejemplo: Desde la debajo del cual se considera generalmente como la mejor práctica. Si ambos están mal, entonces lo que se considera como la mejor práctica.

Opción 1:

   private void BtnPostUpdate_Click(object sender, EventArgs e)
    {
        getValue();
    }

    private void getValue()
    {
        String FileName = TbxFileName.Text;
        int PageNo = Convert.ToInt32(TbxPageNo.Text);

        // get value from Business Layer
        DataTable l_dtbl = m_BLL.getValue(FileName, PageNo);

        if (l_dtbl.Rows.Count == 1)
        {
            TbxValue.Text = Convert.ToInt32(l_dtbl.Rows[0]["Value"]);
        }
        else
        {
            TbxValue.Text = 0;
        }
    }

Opción 2:

    private void BtnPostUpdate_Click(object sender, EventArgs e)
    {
        String FileName = TbxFileName.Text;
        int PageNo = Convert.ToInt32(TbxPageNo.Text);

        int Value = getValue(FileName, PageNo);

        TbxValue.Text = Value.ToString();

    }

    private int getValue(string FileName, int PageNo)
    {
        // get value from Business Layer
        DataTable l_dtbl = m_BLL.getValue(FileName, PageNo);

        if (l_dtbl.Rows.Count == 1)
        {
            return Convert.ToInt32(l_dtbl.Rows[0]["Value"]);
        }
        return 0;
    }

Yo entiendo que podemos pasar parámetros directamente sin asignar a una variable local ... Mi pregunta es más acerca de la definición del método y la forma en que se maneja.

Answer 1

Si está suscribiendo al evento de forma automática, no creo que es particularmente malo tener un método con la firma controlador de eventos, que sólo los delegados a un método que tiene la firma "real" que necesita (en este caso, sin parámetros).

Si se suscriban de forma manual, puede utilizar una expresión lambda en su lugar:

postUpdateButton.Click += (sender, args) => PostUpdate();

y luego hacer el trabajo en PostUpdate. Ya sea que luego dividir el PostUpdate en dos métodos, uno para hacer frente a la interacción de IU y uno para hacer frente a la interacción BLL es de usted. En este caso, no creo que importe demasiado.

El modo de estructurar la lógica de interfaz de usuario para que sea comprobable es un asunto completamente diferente, sin embargo. Me he vuelto recientemente un fan del patrón MVVM, pero no sé cómo sería aplicable que a su escenario particular (que es realmente diseñado en torno a Silverlight y WPF).

Un par de otros comentarios embargo:

• Convencionalmente, los parámetros deben ser CamelCased, no PascalCased
• ¿Usted realmente cree que está recibiendo beneficios de prefijar las variables locales con l_? No es obvio que son locales? Personalmente, no estoy interesado en la mayor parte de los nombres de las variables que se muestran aquí -. Considere denominar las variables después de su significa en lugar de su type
• El uso de un DataTable para devolver información de una manera un tanto propenso a errores de hacer las cosas. ¿Por qué el BLL no devolver un int? para indicar el valor (o la falta de valor)?

Answer 2

Esto es lo que gusta a si yo no implementan MVC. y yo estoy asumiendo web aquí.

Me haría opción 2 principio, pero en lugar de tener el código de botones de establecer el ID de texto crear una propiedad para establecer el valor de los rectángulos de texto.

Lo hago porque si algo conjuntos demás el valor de texto, entonces van a código duplicado. mal si cambia el nombre o tipo de control.

Answer 3

De acuerdo con el ejemplo, la opción 2 es el camino a seguir. Opción 1 sabe acerca de su forma y la forma de mostrar los datos en él, lo cual viola la SRP .