.net - kendo - telerik asp net mvc documentation

Mejores prácticas para DataBinding en asp.net para facilidad de mantenimiento

Question

Me gustaría saber cuáles son las mejores prácticas para usar el enlace de datos asp.net, en términos de mantenibilidad.

No quiero que la aplicación caiga de repente cuando tengo que hacer cambios en la base de datos.

¿Debería enlazarme completamente en codebehind? Estoy planeando usar ObjectDataSources para el enlace de datos. ¿Hay algo que sea más fácil de mantener que el uso de enlace de datos? De ser así, ¿qué es?

¿Hay consideraciones que debería tener en cuenta al diseñar mi capa de acceso a datos y mi capa de negocios?

Gracias.

Answer 1

Mi filosofía sobre esto es que las cosas de acceso a datos no tienen nada que ver en el marcado. Las fuentes de datos de objeto son mejores que las fuentes de datos de SQL, pero me gusta mantener mi marcado como único material que se procesará en la página. También prefiero el control que tienes sobre qué cosas está enlazado a datos que obtienes siempre desde el código subyacente.

Answer 2

Solo para completar, quiero agregar esto sobre mi comentario en la primera respuesta.

Hice la siguiente pregunta:

si enlaza datos desde el código subyacente, igual tendrá que definir sus campos en el marcado. ¿Cómo se aseguraría de que los cambios en sus objetos comerciales no rompan las páginas?

Cuando Databinding, si emite su objeto, se detectará en tiempo de compilación, si el nombre de una propiedad ha cambiado o si ya no existe.

Ejemplo:

<%# ((ObjetType)Container.DataItem).PropertyName %>

Además, al hacer esto, evitará el uso de Eval, que se informa que es lento porque usa reflexión. (Realmente no verifiqué el impacto en el rendimiento)

Answer 3

¡Buena pregunta!

En lo que respecta al enlace de datos, debe considerarlo como un solo componente de su estrategia global de acceso a los datos. Mi estrategia tiene tres componentes (llego a su DataBinding en el componente 2):

Primero, siempre creo (o reutilizo, principalmente) una Capa de acceso a datos (DAL) para simplificar el acceso a los datos. Esto no se debe a que algún día pueda intercambiar su base de datos por otra, las posibilidades de que sean lo suficientemente escasas como para no justificar todo el trabajo que se requeriría (YAGNI). Haga esto para que pueda A) eliminar todo el desorden del código normal de la base de datos (por ejemplo, obtener la cadena de conexión, configurar y cerrar las conexiones, etc.) y B) simplificar las operaciones comunes con funciones dedicadas.

En segundo lugar, debe implementar ObjectDataSources que encapsulan DataBinding para sus controles de interfaz de usuario. Si has construido un buen DAL, esto se vuelve bastante trivial. Por ejemplo, aquí hay un ObjectDataSource que usa mi DAL:

    [DataObjectMethodAttribute(DataObjectMethodType.Select, true)]
    public List<EnrollListMemberData> GetNameList(int classID, DateTime classDate)
    {
        using (BSDIQuery qry = new BSDIQuery())
        {
            return
                qry.Command(
                    "Select a.ClassDate, a.ClientID, b.FirstName, b.LastName, b.ID From ClassEnroll a inner join Folder b on (a.ClientID = b.ClientID) Where (a.ClassID=@ClassID) AND ")
                    .ParamVal(classID)
                    .Append("(DateDiff(d, a.ClassDate, @ClassDate) = 0) Order By LastName;")
                    .ParamVal(classDate)
                    .ReturnList<EnrollListMemberData>();
        }
    }

Algunas cosas a tener en cuenta: el atributo "DataObjectMethodAttribute" hará que este método sea visible para el entorno de tiempo de diseño, de modo que lo verá en la lista desplegable de fuentes de datos cuando vaya a vincular su Grid (o lo que sea) . También necesitará el atributo [DataObjectAttribute] en la clase que proporciona este método (esta clase si forma parte de mi Business Layer). Finalmente, este es un ejemplo bastante simple y no tiene algunas construcciones comunes como los parámetros startRowIndex y maximumRows para devolver resultados paginados.

Tenga en cuenta que la llamada particular aquí es de mi DAL - no es LinqToSQL aunque tiene una similitud de superficie. Me gusta SQL y no quiero las expresiones idiomáticas de C # que de todos modos tienen una asignación arbitraria a SQL . Tenga en cuenta que si intento implementar todo esto en llamadas directas de ADO, esta función sería tres veces más larga y tendría MUCHOS códigos que realmente no estaban relacionados con la expresión de mis objetivos.

En tercer lugar, coloco siempre las operaciones de la base de datos de varios pasos en procedimientos almacenados para minimizar el número de llamadas a través de la conexión a la base de datos. Por ejemplo, proporciono una función de "Ingreso" en un producto que solicita un cheque, lo compara con una tabla de membresía, recupera el historial de cheques anterior (¿Cuántas visitas en el último mes?), Otorga puntos de incentivo si corresponde. etc. Ejecutar múltiples consultas y cambios a la base de datos en el código C # sería terriblemente complejo y bastante caro. De acuerdo con nuestra filosofía DAL, también encapsulado la llamada al procedimiento almacenado en mi DAL para que la llamada real del código sea justa:

int status = dal.CheckIn (userID, ref checkInHistory);

Como puede ver, usar un procedimiento almacenado y encapsularlo en un método de clase C # también hace que el código sea mucho más fácil de leer. Mi código solo dice lo que hace (como arriba) en lugar de tener más de 100 líneas de código configurando consultas, etc.

¡Espero que esto ayude!