¿Hay alguna razón negativa para usar una solución N-Tier?

Question

Soy bastante nuevo en mi empresa (2 semanas) y estamos comenzando una nueva plataforma para nuestro sistema usando .NET 3.5 Team Foundation de DotNetNuke. Nuestro "arquitecto" sugiere que usemos un proyecto de clase. Por supuesto, repito con una arquitectura de "3 niveles" (Business, Data, Web class projects).

¿Hay alguna desventaja al usar esta arquitectura? Pro sería separación de código de datos, manteniendo los objetos de clase lejos de su código, etc.

Answer 1

supongo que un bastante grande inconveniente es que el volumen adicional de código que tiene que escribir, gestionar y mantener para un proyecto pequeña sólo puede ser excesiva.

Todo depende de lo que sea apropiado para el tamaño del proyecto, la vida esperada del proyecto final y el presupuesto. A veces, mientras que hacer las cosas "apropiadamente" es atractivo, ¡hacer algo un poco más "ligero" puede ser la decisión comercial correcta!

Answer 2

tiende a tomar un equipo inexperto más tiempo para construir 3-tier.Es más código, por lo que hay más errores. Sin embargo, solo estoy jugando al abogado del diablo.

Answer 3

Estaría presionando mucho para el enfoque en N niveles, incluso si se trata de un proyecto pequeño. Si utiliza una herramienta ORM como codesmith + nettiers, podrá configurar rápidamente los proyectos y desarrollar un código que resuelva rápidamente sus problemas comerciales.

Me mata cuando empiezas un nuevo proyecto y te pasas días sentado alrededor de ruedas girando hablando de cómo la arquitectura debe ser diseñada. Desea pasar tiempo resolviendo el problema comercial, no resolviendo problemas que otras personas han resuelto para usted. Usar un ORM (realmente no importa cuál, solo elegir uno y mantenerlo) para ayudarlo a obtener la tracción inicial le ayudará a mantenerse enfocado en los objetivos del proyecto y no distraerlo tratando de resolver problemas de "arquitectura".

Si, al final del día, el arquitecto quiere ir al enfoque de un proyecto, no hay ninguna razón para no crear una carpeta app_code con una carpeta BLL y DAL para separar el código por ahora que ayudará te mueves a una solución N-Tiered más tarde.

Answer 4

Como con cualquier cosa, la abstracción crea complejidad, por lo que la complejidad de hacer N-tiered debería justificarse adecuadamente, por ejemplo, ¿el N-tiered en realidad beneficia al sistema? No será pequeños sistemas que funcionarán mejor con N-tiered, aunque muchos de ellos no lo harán.

Además, incluso si su sistema es pequeño en este momento, es posible que desee añadir más características a ella más tarde - no va N niveles fuerza constituirá un órgano tipo de deuda técnica de su parte, así que hay que ten cuidado.

Answer 5

Dado que desea la capacidad de poder distribuir las capas en diferentes niveles físicos (siempre uso "nivel" para físico y "capa" para lógico), debe pensar dos veces antes de simplemente poner todo en uno clase porque tienes refactorizaciones importantes para hacer si o cuando necesitas comenzar a distribuir.

Answer 6

La única desventaja es la complejidad pero realmente lo difícil que es agregar algunos objetos de dominio y vincularlos a una lista de ellos en lugar de usar un conjunto de datos. Ni siquiera tiene que crear tres proyectos separados, solo puede crear 3 carpetas separadas dentro de la aplicación web y darle a cada una un espacio de nombres como, SuCompañía.DomainAyuda, SuEmpresa.Su.Apágina, etc.

El La gran ventaja es tener una solución más flexible.Si comienza a escribir su aplicación como una aplicación centrada en datos, uniendo fuertemente sus páginas de formularios web a conjuntos de datos, terminará haciendo mucho más trabajo luego migrando a un modelo más centrado en un dominio a medida que su lógica de negocio crezca en complejidad.

Quizás en el corto plazo se concentre en una solución simple creando objetos de dominio muy simples y rellenándolos de conjuntos de datos, luego puede agregar lógica comercial según sea necesario y construir un ORM más sofisticado según sea necesario, o usar nhibernate .