2009-10-25 9 views
8

Estoy en el proceso de aprender ASP.NET. Compré algunos libros sobre el tema. Todos ellos sugieren que el uso de los controles de origen de datos, como ObjectDataSource/SqlDataSource, etc. es el camino a seguir. Ahora, definitivamente no soy un experto en el tema, lejos de eso en realidad. pero tengo una fuerte sensación de que estas son herramientas de juguete. Me cuesta creer que estas clases se usarían en una aplicación de nivel empresarial de nivel real. ¿Estoy en lo cierto? ¿O estas clases realmente tienen un lugar en aplicaciones web a gran escala?¿Es realmente profesional utilizar los controles de fuente de datos en ASP.NET?

Gracias, Avi

+0

Bueno, veo que las opiniones son variadas. Supongo que lo intentaré, solo para obtener una primera impresión, al menos. Tengo la sensación de que lo abandonaré al final. Procedente de un fondo de desarrollo del lado del servidor, me resulta muy difícil poner cualquier lógica en la capa de UI, incluso si es simplemente 'declarativo'. Gracias chicos :) –

Respuesta

10

Estos controles han ganado una mala reputación debido a los desarrolladores inexpertos usarlos sin entenderlas, y los desarrolladores profesionales mirando hacia abajo en ellos como resultado. El mejor consejo que puedo darte es que un profesional usará la herramienta que sea más adecuada y que haga el trabajo sin interferir. Si estas herramientas hacen el trabajo por usted, entonces debe usarlas y no permita que la gente lo menosprecie.

1

Son ideales para rellenar un control dependiente si la consulta es simple, como una lista desplegable de categorías. Son bastante dolorosos para hacer búsquedas personalizadas o similares. Evalúe su enfoque caso por caso.

0

Personalmente, prefiero cablear cosas por mi cuenta. Es bastante simple ejecutar procesos almacenados para recuperar datos y asignarlos a controles de entrada de datos sin utilizar el enlace de datos. También es fácil tomar los datos modificados y agregarlos, actualizarlos o eliminarlos según sea necesario. Las clases de fuentes de datos agregan lo que me parece una capa extra innecesaria. Si fueran significativamente más simples que la forma en que lo hago, podría darles una oportunidad, pero me parecen bastante complejos. Y, aunque no tengo ningún dato de referencia para probar esto, parece que deben ser menos eficientes.

1

No podría estar más de acuerdo - la mezcla en materia de conexión de base de datos con HTML, potencialmente lógica de negocio, etc, etc es una muy mala idea en el mundo moderno de las pruebas unitarias, DDD, TDD, etc.

Habrá Ser situaciones donde sean apropiadas (tal vez la tarea más simple de informes que deben hacerse a toda prisa, maquetas) pero, en general, evitarlas.

2

Creo que se podría argumentar que el uso de ObjectDataSource es razonable, suponiendo que realmente está hablando con un verdadero nivel medio de objetos. Especialmente si los desarrolladores amplían ODS para jugar con su nivel medio.

Los demás se romperán los dedos (segunda ofensa) en mi tienda.

2

Lo primero que debe saber sobre ASP.NET es que, todo lo relacionado con los controles del servidor y el paradigma de formularios web en general, nunca funcionará tan bien como Response.Write(). La idea de los formularios web es llevarte del punto A al punto B lo más rápido posible. Entonces, antes de elegir formas web, debería preguntarse, ¿es este el mejor marco para mi aplicación? Para sitios web de alto tráfico, y/o si le importan mucho los patrones de diseño, elegiría MVC sin lugar a dudas.

Ahora, si elige formularios web, le recomiendo encarecidamente que utilice controles de fuente de datos. Hará tu vida más fácil. No sé cómo se definen aplicaciones de grado empresarial, pero los controles de origen de datos pueden lograr grandes cosas. Te recomiendo que busques en LinqDataSource, EntityDataSource, el nuevo DomainDataSource, el nuevo QueryExtender y cómo funcionan con cualquier fuente de IQueryable.

3

Estoy de acuerdo con Wyatt y pensé que debería agregar un poco más de información.El problema con todos los objetos de origen de datos (distintos de ObjectDataSource) es que no puede dividir su aplicación en niveles lógicos (es decir, interfaz de usuario, lógica comercial, acceso a datos). Está poniendo todo su código de acceso a datos en su UI, y eso es muy malo desde una vista arquitectónica de su proyecto.

+0

Gracias por la respuesta Jason. Solo tengo una pregunta sobre algo en su comentario. Usted mencionó que, de hecho, todos los controles de fuente de datos pueden ser problemáticos en una aplicación de varios niveles, excepto en ObjectDataSource. ¿Estás diciendo que este control específico realmente puede usarse en una aplicación de niveles múltiples? Y si puede, ¿se recomienda usarlo en tales escenarios? Gracias por su tiempo –

+0

ObjectDataSource se puede utilizar en una aplicación de varios niveles, ya que puede "conectarlo" a los objetos de su capa empresarial. Definitivamente podría usarse como una forma de acceder a toda la funcionalidad de una fuente de datos vinculada con una aplicación de varios niveles. –

1

La afirmación de que un control de fuente de datos coloca el código directamente en el formulario no es necesariamente una afirmación correcta. Normalmente tiene una clase de controlador y vincula el control de fuente de datos al método del controlador.

Aún tiene su nivel medio y todo lo demás. Como dijo un afiche, usualmente son desarrolladores con experiencia que arruinan el por qué estos controladores son valiosos. Manejan todas las tuberías de la página y aún tiene separación entre la interfaz de usuario y el nivel medio (controlador).

Pero también depende si usted es más un programador que prefiere los objetos de dominio que se oponen a los conjuntos de datos.

Cuestiones relacionadas