¿Merece la pena utilizar arquitectura de 3 capas para aplicaciones pequeñas (ISH)

Question

Estoy trabajando en una aplicación relativamente pequeña asp.net web y estoy preguntando si realmente hay una necesidad de emplear una arquitectura completa de n niveles. Para tener una idea de su tamaño; hay cerca de 20 tablas de la base.

En el pasado he utilizado un enfoque de 2 niveles, donde la lógica de negocio y acceso a datos se agrupan en una única biblioteca de clases con el era una aplicación web asp.net formación de la capa de interfaz de usuario y esto parecía funcionar bien.

¿Hay un umbral de tamaño o alguna regla de oro donde se debe emplear n-tier?

Answer 1

Puede ser relativamente pequeña ahora, pero ¿cree que podría crecer en el futuro? Por su supuesto que tiene que ser pragmático, pero si ya tiene separaciones naturales de interés dentro de su conjunto único, entonces es bastante fácil de dividir que en dos o más conjuntos. Si las clases mismas combinan la lógica de negocio y acceso a datos, entonces usted tiene más trabajo en sus manos. Sin embargo, yo diría que es casi más trabajo para escribir su lógica de acceso a datos en un solo montaje y su lógica de negocio en la otra, en paralelo, si es necesario, que escribir todo en un solo lugar en el primer lugar.

Answer 2

Si usted anticipa crecimiento o cambio de cualquier tipo, que ayudaría a reforzar los niveles explícitos ahora. Pero si este es su propio proyecto y no le importa ponying el coste del cambio o código estrechamente integrada, a continuación, sólo cortar lejos en él como una capa.

Se trata de costo futuro. En la actualidad, solo la programación a medida que avanza es, con mucho, el más barato, pero no responde a cambios muy bien. Con la planificación de nivel, hay un costo inicial, pero se puede manejar el cambio y la rasgadura de implementaciones de la capa entera mejor que el primer enfoque lata.

Así que su regla de oro es gobernado por quien va a pagar por el cambio y cuándo.

Answer 3

Sí vale la pena. Lo que usted propone es la piratería una solución juntos. No puedo decirle cuántas veces esto me ha traído dolor y sufrimiento. La otra cara de la moneda es que los desarrolladores astronaught overbuild sus soluciones. Se quiere evitar esto también.

ser simple, construir sus tres capas, le sugiero que pruebe LINQ a SQL, que hace que la construcción de la CHA en un instante, y luego usted puede centrarse en la construcción de una interfaz de usuario delgada, y una BLL que controlará el trabajo pesado. No le llevará mucho más tiempo para hacerlo y que permitirá a la unidad de pruebas después.

Answer 4

  

¿Hay un tamaño umbral o alguna regla   de oro donde se debe emplear   n-tier?

No es que yo sepa, pero voy a tirar esto: si hay una posibilidad de esta aplicación web puede crecer (o cambio backends) y / o cualquier otra persona puede terminar su mantenimiento, lo consideraría ir con un enfoque de n niveles.

Answer 5

Sólo mantenerlo posible. Es probablemente demasiado ahora, pero no escriben a sí mismo en una situación en la que es imposible. Refactorización a gran escala le llevará más tiempo que la reconstrucción desde cero (y probablemente será sólo eso, reconstruir desde cero).

El último proyecto que trabajé (llegó tarde) fue escrito de una manera que romper las gradas era prácticamente imposible. la lógica de datos entretejida con la lógica de negocio entretejida con la lógica de presentación. En el corto plazo, que era tan buena como lo fue siempre va a ser porque fijándolo hubiera tomado varios meses.

No es demasiado difícil de mantener todo separado por lo que como he dicho antes, si prefieres algo posible.