¿Vale la pena utilizar la arquitectura de 3 niveles para aplicaciones pequeñas (ish)?

Question

Estoy trabajando en una aplicación web asp.net relativamente pequeña y me pregunto si realmente es necesario emplear una arquitectura completa de n niveles. Para una idea de tamaño; hay alrededor de 20 tablas de base de datos.

En el pasado utilicé un enfoque de dos niveles donde la lógica de negocios y el acceso a datos se agrupan en una sola biblioteca de clase con una aplicación web asp.net formando el nivel UI y parecía funcionar bien.

¿Existe un límite de tamaño o alguna regla general donde debe emplear n-tier?

Answer 1

Puede ser relativamente pequeño ahora, pero ¿cree que podría crecer en el futuro? De su curso, debe ser pragmático, pero si ya tiene separaciones naturales de preocupación dentro de su ensamblaje único, entonces es bastante fácil dividirlo en dos o más ensamblajes. Si las clases combinan la lógica comercial y el acceso a los datos, entonces tendrá más trabajo en sus manos. Sin embargo, diría que ya casi no es necesario escribir su lógica de acceso a datos en un ensamblaje y su lógica de negocios en el otro, en paralelo si es necesario, que escribir todo en un solo lugar en primer lugar.

Answer 2

Si prevé un crecimiento o cambio de cualquier tipo, ayudaría a reforzar los niveles explícitos ahora. Pero si este es su propio proyecto y no le importa comparar el costo del cambio o el código estrechamente integrado, simplemente corte como una capa.

Se trata de un costo futuro. En el presente, solo la programación sobre la marcha es de lejos la más barata, pero no responde al cambio muy bien. Con la planificación de niveles, hay un costo inicial, pero puede manejar el cambio y eliminar implementaciones de capas enteras mejor de lo que puede hacerlo el primer enfoque.

Así que su regla de oro se rige por quién pagará el cambio y cuándo.

Answer 3

¿Hay un tamaño umbral o alguna regla del pulgar donde se debe emplear n niveles?

Ninguno de los que conozco, pero lo descartaré: si hay una posibilidad de que esta aplicación web pueda crecer (o cambiar de backends) y/o que otra persona termine manteniéndola, yo ' considerar ir con un enfoque de n niveles.

Answer 4

Sí, vale la pena. Lo que estás proponiendo es hackear una solución juntos. No puedo decirte cuántas veces esto me ha traído dolor y sufrimiento. El otro lado de esa moneda son los desarrolladores de astronautas que sobre compilan sus soluciones. Usted quiere evitar esto también.

Sea simple, construya sus tres capas, le sugiero que pruebe LINQ to SQL, hace construir el DAL en un abrir y cerrar de ojos, y luego puede enfocarse en construir una interfaz de usuario delgada y un BLL que manejará el trabajo pesado. No le tomará mucho más tiempo hacerlo y permitirá pruebas unitarias más adelante.

Answer 5

Solo manténgalo posible. Probablemente ya sea excesivo pero no te escribas en una situación en la que es imposible. La refabricación a gran escala te llevará más tiempo que reconstruirla desde cero (y es probable que sea solo eso, reconstruyendo desde cero).

El último proyecto en el que trabajé (llegó tarde) fue escrito de manera que dividir los niveles era prácticamente imposible. Lógica de datos entretejida con lógica de negocios entretejida con lógica de presentación. En el corto plazo, fue tan bueno como lo fue alguna vez porque arreglarlo hubiera llevado varios meses.

No es muy difícil mantener todo separado así que como dije antes, solo hazlo posible.