¿Existe alguna razón negativa para utilizar una solución de N niveles?

Question

Soy bastante nuevo en mi empresa (2 semanas) y estamos iniciando una nueva plataforma para nuestro sistema utilizando .NET 3.5 Team Foundation de DotNetNuke.Nuestro "arquitecto" sugiere que utilicemos un proyecto de clase.Por supuesto, repito con una arquitectura de "3 niveles" (proyectos de clase empresarial, de datos y web).

¿Existe alguna desventaja al utilizar esta arquitectura?Las ventajas serían la separación del código de los datos, mantener los objetos de clase alejados de su código, etc.

Answer 1

Supongo que una desventaja bastante grande es que el volumen adicional de código que hay que escribir, administrar y mantener durante un pequeño El proyecto puede ser simplemente excesivo.

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

Answer 2

A un equipo sin experiencia le suele llevar más tiempo construir 3 niveles. Es más código, por lo que hay más errores.Aunque sólo estoy haciendo el abogado del diablo.

Answer 3

Estaría presionando mucho por el enfoque de niveles N 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 código que resuelva sus problemas comerciales rápidamente.

Me mata cuando empiezas un nuevo proyecto y pasas días sentado dando vueltas a ruedas hablando sobre cómo se debe diseñar la "arquitectura".Quiere dedicar tiempo a resolver el problema empresarial, no a resolver problemas que otras personas han resuelto por usted.Usar un ORM (realmente no importa cuál, simplemente elige uno y mantenlo) para ayudarte a obtener tracción inicial te ayudará a mantenerte enfocado en los objetivos del proyecto y no te distraerá tratando de resolver problemas de "arquitectura".

Si, al final del día, el arquitecto quiere seguir el enfoque de un solo proyecto, no hay ninguna razón por la que no pueda crear una carpeta app_code con una carpeta BLL y DAL para separar el código por ahora, lo que le ayudará a pasar a un Solución de N niveles más adelante.

Answer 4

porque quieres el capacidad de poder distribuir las capas en diferentes niveles físicos (siempre uso "nivel" para físico y "capa" para lógico), deberías pensarlo dos veces antes de poner todo en una clase porque tienes que hacer refactorizaciones importantes si o cuando necesite comenzar a distribuir.

Answer 5

Como ocurre con cualquier cosa, la abstracción crea complejidad, por lo que la complejidad de realizar N niveles debe justificarse adecuadamente; por ejemplo, ¿los N niveles realmente benefician al sistema?Allá voluntad Habrá sistemas pequeños que funcionarán mejor con N niveles, aunque muchos de ellos no lo harán.

Además, incluso si su sistema es pequeño en este momento, es posible que desee agregarle más funciones más adelante, sin pasar a N niveles. podría constituyen una especie de deuda técnica por tu parte, por lo que hay que tener cuidado.

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, simplemente puede crear 3 carpetas separadas dentro de la aplicación web y darle a cada una un espacio de nombres como YourCompany.YourApp.Domain, YourCompany.YourApp.Data, etc.

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, acoplando 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 el dominio a medida que su lógica de negocios crece en complejidad.

Tal vez en el corto plazo se concentre en una solución simple creando objetos de dominio muy simples y completándolos a partir de conjuntos de datos, luego pueda agregarles lógica de negocios según sea necesario y construir un ORM más sofisticado según sea necesario, o usar nhibernate.