¿Por qué debería usar un enfoque N-Tier Cuando el uso de un SqlDatasource es MUCHO MÁS FÁCIL?

Question

Cuando se trata de desarrollo web, siempre he intentado trabajar INTELIGENTE, NO DIFÍCIL. Así que por largo tiempo Mi aproximación al interactuar con bases de datos en mis proyectos de la Red PEA ha sido la siguiente:

1) Crear mis procedimientos almacenados

2) Arrastre un control SqlDataSource en mi página aspx

3) se unen de una control DataList a mi SQLDataSource

4) insertar, actualizar & borrar con mi DataList o mediante programación utilizando una función en los métodos SQLDataSource por ejemplo

MySqlDataSource.InsertParameters["author"].DefaultValue = TextBox1.Text; 

MySqlDataSource.Insert(); 

Recientemente, sin embargo, obtuve un proyecto web relativamente fácil. Así que decidí emplear un modelo de 3 niveles ... ¡Pero me agotó a mitad de camino y simplemente no parecía valer la pena! Parecía que estaba trabajando demasiado DURO para un proyecto que podría haberse logrado fácilmente con un par de controles SqlDataSource.

Entonces, ¿por qué el modelo N-Tier es mejor que mi enfoque? Tiene algo que ver con el rendimiento? ¿Cuáles son las ventajas del control ObjectDataSource sobre el control SqlDataSource?

Answer 1

que se acercó a las cosas al revés. El enfoque SQLDataSource es para pequeños proyectos livianos. Tan pronto como crezcas, querrás reutilizar estructuras y consultas entre muchas páginas diferentes.

Con su enfoque, esto significa aplicar el patrón de diseño de copiar/pegar de una página a otra solo para que pueda usar la misma consulta.Ahora piense qué sucede cuando algo cambia (la estructura de la base de datos, por ejemplo) y tiene que replicar esos cambios entre 50 páginas que tienen literales de SQL incrustados en ellas: se encuentra en un mundo herido.

Aquí viene el modelo de n niveles para el rescate: la lógica de acceso a datos debe estar aislada en su propio nivel y solo debe haber un código responsable de cierta lógica empresarial/de datos y si es necesario realizar cambios solo habría que cambiar un código. El problema con este enfoque es que requiere más esfuerzo por adelantado y la amortización solo es visible en proyectos razonablemente grandes.

Answer 2

Aquí hay un par de razones para n niveles:

1. n-tier significa una mejor escalabilidad. Puede agregar servidores de nivel medio para escalar si el servidor de la base de datos no puede mantener el ritmo.
2. n-tier le permite agregar seguridad fuera de la base de datos (por ejemplo, servidores de directorio de la empresa).
3. n-tier le ofrece un intermediario que puede verificar la inyección SQL, validando y vinculando variables desde la interfaz de usuario.
4. n-tier can mean looser coupling. SqlDataSourceControl significa que la IU lo sabe todo sobre el esquema de la base de datos. (Este es inestable: si agrega un nuevo campo, el efecto se propagará a través de la IU sin importar lo que haga).
5. Un nivel intermedio hace posible que otra IU reutilice la funcionalidad.

Si solo está escribiendo una aplicación web CRUD, sin posibilidad de compartir y buena escalabilidad, su enfoque podría estar bien.

Answer 3

No hay ningún problema con el uso del control SqlDataSource si lo desea. Dicho esto, hay muchas razones válidas para usar un sistema de N niveles.

1. fuertemente parejas su presentación de capa a capa de datos
2. duplica un montón de trabajo
3. consultas SqlDataSource son a menudo única

Answer 4

Si no está construyendo proyectos medianos o grandes, ha descubierto el secreto aquí.

n-tier solo ayuda a aplicaciones más grandes; debajo de esos, es un ejercicio de práctica en el mejor de los casos, y un notable colapso a pesar de todo.

Answer 5

He descubierto que la primera vez que se comienza a crear un prototipo de su aplicación es mucho más rápido utilizar el objeto SQLDataSource. Puede pasar a través de una cantidad significativa de diseño rápido de aplicaciones web usando este método primero. A medida que su aplicación comienza a crecer y refleja la necesidad de pasar a utilizar un servicio web para la conectividad de n niveles de la base de datos, puede tomar su decisión en ese momento. Algunos de los beneficios son la producción de una aplicación web funcional para demostrar a los clientes. Una vez que acepten el diseño y el enfoque, puede tomar la decisión de convertir las consultas en un servicio web. Esto no es muy difícil ya que ya ha creado las consultas dentro del SQLBuilder y ahora solo tiene que establecer/mover estas mismas consultas desde un servicio web, y luego llamar a las consultas del servicio web apropiado desde la capa de la interfaz de usuario.

Esto tomará tiempo, pero la aplicación web prototipo ya ha demostrado que el enfoque es aceptable y ha evitado retrasos considerables al pasar por un servicio web antes de que sea, o tal vez no sea necesario.