2009-07-30 13 views
14

Si una página web necesita algunos datos, ¿por qué no simplemente hacer que una llamada a SQLDataSource sea un procedimiento almacenado? ¿Por qué usar ObjectDataSource para llamar a un objeto comercial que luego llama al procedimiento almacenado? Entiendo que otras aplicaciones (digamos aplicaciones de escritorio) creadas en el .NET Framework pueden acceder a los objetos comerciales, pero ¿qué pasa si la aplicación siempre será solo una aplicación web?SqlDataSource vs ObjectDataSource

Para ser más claro:

¿Cuándo se debe utilizar un SqlDataSource o ObjectDataSource?

¿Cómo se motiva la elección?

Respuesta

22

Tener solo un SQLDataSource es perfectamente válido, si se trata simplemente de una demostración, un prototipo o un hack rápido. Es rápido, es fácil, solo funciona y te da los resultados que necesitas.

Sin embargo, cuando una aplicación se diseña y construye a largo plazo y anticipa que las cosas (requisitos, deseos del cliente, eventualmente el esquema de la base de datos) pueden cambiar, entonces podría tener mucho más sentido introducir una adecuada " capa de negocios: modele sus objetos comerciales como objetos y luego proporcione una asignación desde la base de datos subyacente a esos objetos comerciales.

Como dice el refrán: se puede resolver casi cualquier cosa en informática por una capa más de indirección (o abstracción) - lo mismo ocurre aquí.

SEGURO: puede ir directamente a la base de datos, y seguro, al principio y para la primera iteración, es posiblemente (o probablemente) la forma más rápida. Pero a la larga, cuando una aplicación está diseñada para durar, generalmente es una forma rápida y-dirty: el costo de mantenimiento, el costo de mantenimiento, el costo y el esfuerzo necesarios para cambiar de acuerdo con sus necesidades y las de su cliente crecerá y bastante rápido, esa solución rápida no se ve tan grande en términos de esfuerzo.

Así que para resumir: sí, inicialmente, usar una fuente de datos SQL directa podría ser más rápido y más fácil, así que úselo cuando ese sea el punto importante: hacer las cosas para una demostración rápida, una prueba de concepto de estilo de la aplicación. Pero a la larga, cuando observas la vida útil de una aplicación, por lo general vale la pena invertir un poco más (diseño y codificación) para agregar esta capa de abstracción para que tus páginas web no dependan directamente de los detalles de la base de datos debajo.

Marc

+0

mientras estoy de acuerdo con todos sus puntos y su respuesta está bien escrita, sus páginas ahora no dependen de los detalles de su base de datos, pero sí de sus objetos comerciales. ¿Qué ventaja trae esto? –

+4

La ventaja es: si su base de datos cambia, pero sus objetos comerciales siguen siendo los mismos, la interfaz de usuario aún funciona. Si usa SqlDataSource directamente, y como muchos lo hacen, use un 'SELECT * FROM ....' su código probablemente se bloqueará en el momento en que otro campo se agregue a la tabla de la base de datos. Este no será el caso si tiene una capa de negocios intermedia. –

+1

Además, al empaquetar sus datos en objetos comerciales, es mucho más fácil trabajar con ellos. Tienes, por ejemplo, un objeto "Cliente", para el que puede leer y escribir propiedades como "ID de cliente", "Nombre", etc. - no tiene que lidiar con las intrigas de las filas y campos de la base de datos y hacer todas las conversiones cada vez que accede a datos. –

2

Si tiene una capa empresarial que está utilizando en sus proyectos, ObjectDataSource es la elección natural. Esto encaja bien con muchos ORM, y muchos de ellos brindan beneficios adicionales (validación, deshacer, etc.). También le permite acceder a cualquiera de las otras propiedades & que tiene en sus objetos comerciales, no solo a los campos SQL directos. Esto puede ser muy útil cuando se vincula, ya que le permite vincular las propiedades en el marcado en lugar de tener que escribir una gran cantidad de código.

Si va por esta ruta, mezclar SQLDataSource y ObjectDataSource puede llevar a la confusión del próximo desarrollador para recoger su proyecto. En este caso, me quedo con ObjectDataSource para la coherencia del código.

Si no tiene una capa empresarial y solo está accediendo directamente a SQL, use SQLDataSource. Mi preferencia personal es que todo su código SQL debe estar en una capa empresarial o de datos, y debido a que casi nunca uso SQLDataSource.

1

si se puede applay su código de capa de negocio en el procedimiento almacenado la que es mejor usar SQLDataSource

0

En teoría ObjectDataSource es mejor. Pero todo eso depende de qué tan bien esté escrito y documentado el modelo de objetos. Externalizamos una empresa que usó un generador de códigos personalizado (que no nos proporcionarían) para producir todas las capas. Resultó ser una pesadilla hacer incluso pequeños cambios, como agregar una propiedad o cambiar un tipo de campo. Ahora estoy eliminando prácticamente todo lo que hicieron y simplemente usando los procedimientos almacenados que escribieron.

Mi objetivo a largo plazo es volver a escribir la aplicación desde cero utilizando una herramienta de modelado comercial & generador de códigos. Si vas a usar objectdatasource, recomiendo encontrar una buena herramienta de modelado que incluya un generador de código flexible.

Cuestiones relacionadas