design - servidor - ¿Cuán estrictamente sigues la arquitectura de n niveles y la separación de preocupaciones entre las capas en tus proyectos?
arquitectura n-capas (6)
Supongo que la mayoría de los desarrolladores tienen una idea de arquitectura multicapa. Tenemos DAL (capa de acceso a datos), tenemos BLL (capa de lógica de negocios) y en algún lugar cerca del final de la carretera tenemos nuestra UI. Si tiene un proyecto que de alguna manera sigue estos principios, ¿se queda (o al menos intenta) para mantener / poner las cosas donde pertenecen conceptualmente? Estoy especialmente interesado en las aplicaciones de grandes empresas donde trabajas junto con muchas otras personas. Es evidente que puede hacer lo que quiera con su proyecto de juguete privado, inventar cualquier tipo de arquitectura y atenerse a ella. No es tan fácil con grandes proyectos donde mucha gente contribuyó al software o al desorden general.
Por ejemplo, sucedió que cosas como los componentes de la IU van directamente a la base de datos para obtener datos extra "faltantes" que BL no proporciona, también UI y BL trabajando con elementos de bajo nivel como campos de tablas donde, en mi opinión, deberían delegar estas operaciones al nivel inferior, es decir, DAL. Fue especialmente triste cuando, después de discutir las cosas con el desarrollador principal, vi que no veía ningún problema con esto.
Por supuesto, podemos suponer que yo y quien comparta mi punto de vista somos simplemente perfeccionistas, pero claramente vi una consecuencia muy desventajosa ya que me llevó largos períodos de tiempo en algunas de mis tareas rastrear todas las rutas "paralelas" que el los datos viajan hacia y desde la base de datos e identifican a quién y de qué manera ahora puede verse afectado por la nueva funcionalidad que implementé. De la forma en que lo veo, estos son mayores costos de desarrollo / mantenimiento, sobreponderando algunos ahorros cuando alguien decide piratear rápidamente las cosas y cerrar la tarea lo antes posible.
¿Son proyectos "puros" o abandonaron la idea de mantener la línea clara entre las capas hace mucho tiempo? Si sigues manteniéndolo bien, ¿cómo lidias con colegas que no entienden estas cosas o que no se preocupan por ellos simplemente creando soluciones "personalizadas" y pirateando hacks todo el tiempo? ¿O en algún momento dejaste de luchar con el molino de viento y lo aceptaste como tu castigo? EDITAR: Algo sorprendido de que no mucha gente se interesó por el problema. ¿Es ese el letrero que a la mayoría no le importa?
¡Esa es una gran pregunta! Algo que cada desarrollador ASP.Net necesita pensar. Probablemente obtendrás muchas respuestas, recomendaría estas ideas básicas de sentido común.
- Considere la simplicidad y la velocidad de entrega como parte de una arquitectura "exitosa", no solo de "pureza". Trata de equilibrar entre mantener los ideales arquitectónicos y ser práctico.
- En general, parece tener sentido dividir el código en capas como mencionas. Sin embargo, sugeriría que para la lógica específica de la página, podría dejarse en la página si es más simple / más rápido: por qué crear objetos comerciales genéricos para el código que acaba de usarse en un solo lugar. Como se ha dicho "la optimización prematura es la raíz de todo mal".
--Mantenga las capas y la complejidad al mínimo para reducir el tiempo de codificación y mejorar la legibilidad y el mantenimiento.
Hay muchos puristas en este sitio a los que les gusta hacer arquitectura para el sitio de arquitectura: utilizar la arquitectura como herramienta para ofrecer una solución a un problema comercial, no como una forma de arte por sí misma, sino como una herramienta útil. de lo que te está usando.
Code Monkeys and Purists se parece mucho a cualquier otro extremista en la vida.
Tenemos extrema derecha y extrema izquierda. Muy pocas personas son exactamente una u otra y encuentran un buen término medio donde se sientan. Si no fuera por los extremistas, no sabríamos dónde están los límites.
En lo que respecta a la forma en que codigo. Escucho la forma purista de hacerlo. Veo a los monos codificar sus métodos. Utilizo mi experiencia para elegir un término medio que me brinde la cantidad correcta de flexibilidad y capacidad de administración junto con el tiempo que necesito para producirlo y la cantidad de dinero que realmente obtendré por hacerlo.
Cuanto más complicada sea nuestra aplicación, más importante será la separación de las preocupaciones.
Con 100 klocs, la aplicación era una gran gota, tanto código de negocio en las clases de formulario como en cualquier otro lugar y las llamadas a los métodos de formulario de las clases de negocios. Con muchos gemidos y crujir de dientes, separamos la lógica comercial de la lógica de visualización. Cualquier clase que necesita notificar al usuario de su progreso planteó un evento que fue hundido por la interfaz de usuario. Y, por un tiempo, todo estaba bien con el mundo.
Alrededor de 200 klocs, agregamos una capa de datos. La arquitectura de nuestra aplicación fue tal que la mayoría de nuestros datos se procesaron tan pronto como llegaron y se descartaron inmediatamente. La mayoría de la información de configuración se almacenaba en la aplicación de terceros con la que compartíamos una relación simbiótica. Pero los ajustes comenzaron a acumularse en todo tipo de rincones extraños. Terminamos con tres sistemas de administración de configuración, todos intrincadamente entretejidos en la lógica de negocios. Con una amplia reescritura, pudimos separar la información de configuración en su propia capa y el manejo de la transmisión de datos en otra capa.
Cerca de la línea de 250 kloc, decidimos finalizar nuestra relación con el proveedor externo y hacer que nuestra aplicación sea independiente. Comenzamos una reescritura masiva y, por primera vez, agregamos una base de datos real a nuestra aplicación. Debido a que teníamos líneas claras entre la información de transmisión, el almacenamiento de datos y la lógica de negocios, esta era una integración bastante sencilla.
Ahora, acercándonos a 500 klocs, estamos trasladando la aplicación a una arquitectura basada en grid. No solo la UI se separará de la lógica comercial en una computadora diferente, el cálculo real de las cotizaciones y pedidos que envía la aplicación se balanceará y distribuirá para maximizar la eficiencia. Esto sería imposible sin una arquitectura de n niveles.
En cada etapa de crecimiento, fuimos ayudados por una separación limpia u obstaculizados por nuestro propio embrollo de comunicación, datos, negocios y UI. Probablemente no haya habido una preocupación más importante que esa separación en la creación de esta aplicación.
Cuanto más grande es el código, más larga es la vida, mientras más personas trabajan en el código (tanto de forma simultánea como durante la vida), más importante es la separación en capas. Al principio, parece ser un trabajo un poco más innecesario, pero a la larga se paga por sí mismo varias veces.
En cuanto a la aplicación de la separación: Es por eso que su programador principal o arquitecto técnico necesita buenas habilidades blandas, así como habilidades técnicas puras. Puede intentar imponer la separación técnicamente (ver a continuación), pero al final, debe convencer (o coaccionar) a sus desarrolladores para que mantengan la imagen completa limpia.
Pero esto no quiere decir que los medios técnicos para hacer cumplir la separación no tengan uso. De hecho, descubrí que garantizar que las "llamadas transfronterizas" sean algo difíciles de hacer hará que las personas pasen más tiempo pensando en lo que realmente necesitan en la interfaz transfronteriza, lo que lleva a interfaces más limpias. No importa si la dificultad es técnica (porque tiene que usar COM o CORBA) u otra cosa (debe completar un formulario de 7 páginas por triplicado).
Mantenga las preocupaciones separadas. Es muy muy importante No mezcle la interfaz de usuario con Biz y Biz con la capa de datos. Trabaja con abstracción. Trabajar con abstracción también facilita las pruebas (pruebas unitarias) (simularlas). Guardo estrictamente cada capa donde pertenece. Recuerde que el costo más alto en cualquier proyecto es su mantenimiento. Si mezclas las preocupaciones, el mantenimiento se convertirá en una pesadilla.
Tenemos una aplicación Winforms y una aplicación ASP.NET. Ambos usan el mismo proyecto Business Objects (alrededor de 140 clases).
El proyecto Winforms consta de aproximadamente 350 clases de formulario y control de usuario, y muy pocas (<10) de ellas necesitan metadatos sobre ellos mismos de la base de datos.
El proyecto ASP.NET tiene aproximadamente 100 páginas .aspx.
Tenemos una capa de acceso a datos que consta de 5 clases, que se ocupan de ADO.NET, hilos y transacciones. Convierten solicitudes de Business Objects en llamadas de SQL Server.
Las capas de la interfaz de usuario (con la excepción de las pocas clases que necesitan metadatos sobre el tamaño del formulario) no tienen acceso a la base de datos en absoluto. Incluso las pocas excepciones pasan por el DAL como cualquier otra cosa.
La capa Business no sabe nada sobre el funcionamiento interno de la capa de acceso a datos, y cuando necesita datos, solo llama métodos públicos en las clases DAL.
No soy un fundamentalista en lo que respecta a este tipo de cosas, pero nunca hemos necesitado tomar atajos en este caso.
En resumen, 100% puro. Simplemente siempre es mejor hacerlo bien.
Tendríamos que tener una buena razón para alejarnos de esto ahora.