SqlDataSource vs ObjectDataSource

Question

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

Para ser más claro:

¿Cuándo debería uno usar un SqlDataSource o ObjectDataSource ?

¿Cómo se motiva la elección?

Answer 1

Tener solo un SQLDataSource es perfectamente válido, si es solo una demostración, un prototipo o un hack rápido. Es rápido, es fácil, simplemente funciona y le brinda los resultados que necesita.

Sin embargo, cuando una aplicación está diseñada y construida para el 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 un " negocio " capa: modele sus objetos comerciales como objetos y luego proporcione una asignación de la base de datos subyacente a esos objetos comerciales.

Como dice el dicho: puedes resolver prácticamente cualquier cosa en una ciencia más con una capa más de direccionamiento indirecto (o abstracción): lo mismo se aplica aquí.

SURE: puede ir directamente a la base de datos, y seguro, al principio y para la primera iteración, esa es posiblemente (o probablemente) la forma más rápida. Pero a largo plazo, cuando una aplicación está diseñada para durar, generalmente es una forma rápida y sucia : el costo de mantenimiento, el costo de mantenimiento, el costo y el esfuerzo necesarios para cambiar de acuerdo con sus necesidades y las de sus clientes crecerán y rápidamente, esa solución rápida y sencilla ya no se ve tan bien en términos de esfuerzo.

Para resumir mi punto: sí, inicialmente, usar una fuente de datos de SQL directa puede ser más rápido y más fácil, así que utilícelo cuando sea el punto importante: hacer las cosas para una demostración rápida, una prueba de concepto aplicación de estilo Pero a largo plazo, cuando analiza la vida útil de una aplicación, normalmente vale la pena invertir un poco más de esfuerzo (diseño y codificación) para agregar esta capa de abstracción para que sus páginas web no dependan directamente de los detalles de la base de datos debajo.

Marc

Answer 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 proporcionan beneficios adicionales (validación, deshacer, etc.). También le permite acceder a cualquiera de las otras propiedades & amp; los métodos que tiene en sus objetos comerciales, no solo los campos de SQL directos. Esto puede ser muy útil cuando se vincula, ya que le permite simplemente enlazar a las propiedades en el marcado en lugar de tener que escribir mucho código detrás.

Si va por esta ruta, la combinación de SQLDataSource y ObjectDataSource puede generar confusión en el próximo desarrollador para recoger su proyecto. En este caso, me quedo con ObjectDataSource para la consistencia del código.

Si no tiene una capa empresarial y solo está golpeando directamente a SQL, use el 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.

Answer 3

si puede aplicar el código de la capa empresarial en el procedimiento almacenado Es mejor usar SQLDataSource

Answer 4

En teoría, objectdatasource es mejor. Pero todo depende de qué tan bien esté escrito y documentado el modelo de objetos. Externalizamos una empresa que usaba un generador de código personalizado (que no nos proporcionaban) 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 desechando prácticamente todo lo que hicieron y solo uso 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 & amp; generador de códigos. Si va a utilizar objectdatasource, le recomiendo que busque una buena herramienta de modelado que incluya un generador de código flexible.