Cómo estrictamente sigues la arquitectura de n niveles y la separación de intereses entre las capas en sus proyectos?

Question

supongo que la mayoría de los desarrolladores tienen una idea de la arquitectura de múltiples capas. Tenemos DAL (capa de acceso de datos), tenemos BLL (capa de lógica de negocio) y en algún lugar cerca del final del camino tenemos nuestra interfaz de usuario. Si usted tiene un proyecto que de alguna manera sigue estos principios, es lo que mantener (o por lo menos intentarlo) para mantener / poner las cosas donde pertenecen conceptualmente? Estoy especialmente interesado en aplicaciones de gran empresa en la que trabaja junto con muchas otras personas. Es evidente que puede hacer lo que quiera con su proyecto juguete privada, inventar cualquier tipo de una arquitectura y se adhieren a ella. No es tan fácil con grandes proyectos donde muchas personas han contribuido al software o desorden general.

Por ejemplo, me pasó a ver cosas como componentes de interfaz de usuario que van directamente a la base de datos para ir a buscar un poco de "falta" de datos extra que BL no proporciona, también, tanto la interfaz de usuario y BL trabajar con elementos de bajo nivel como campos de la tabla, donde en mi opinión deben delegar estas operaciones al nivel inferior a saber DAL. Fue especialmente triste cuando después de discutir las cosas con el tipo de programador senior vi que no ve un problema con esto en absoluto.

Podemos, por supuesto, me asumir y el que comparte mi punto de vista son simplemente ser perfeccionistas, pero vi claramente una consecuencia muy disadvantegous en que me tomó períodos prolongados de tiempo en algunas de mis tareas para rastrear todo el "paralelo" rutas que viajan los datos hacia y desde la base de datos e identificar quien y de qué manera ahora puede verse afectada por la nueva funcionalidad he implementado. La forma en que lo veo, éstos se incrementan aún más los costos de desarrollo / mantenimiento sobreponderación algunos ahorros cuando alguien decidió cortar rápidamente las cosas y cerrar la tarea tan pronto como sea posible.

¿Estás proyectos "puro" o abandonaron la idea de mantener la línea clara entre las capas hace mucho tiempo? Si aún así mantener las cosas bien, ¿cómo lidiar con los colegas que no entienden estas cosas o no se preocupan por ellos acaba de soluciones "a medida" y hacks piratería todo el tiempo? O en algún momento en el tiempo que dejó de luchar con el molino de viento y la aceptó como su castigo ?. EDIT: Un poco sorprendido de que no mucha gente se interesó en el problema. Es que el signo más no me importa?

Answer 1

El más complicado nuestra aplicación obtiene, la separación más importante de las preocupaciones se convierte.

A 100 klocs, la aplicación fue una gran mancha, tanto código de negocio en las clases de formulario como en cualquier otro lugar y pone en métodos de formulario de las clases de negocios. Con mucho llanto y crujir de dientes, separamos a cabo la lógica de negocio de la lógica de visualización. Cualquier clase que necesita para notificar al usuario de su progreso provoca un evento que fue hundido por la interfaz de usuario. Y, por un tiempo, todo estaba bien en el mundo.

Alrededor de 200 klocs, hemos añadido una capa de datos. La arquitectura de nuestra aplicación era tal que la mayoría de nuestros datos se procesaron en cuanto entró e inmediatamente descartados. La mayoría de la información de configuración se almacena en la aplicación de terceros con los cuales el nuestro comparten una relación simbiótica. Sin embargo, la configuración empezaban a acumularse en todo tipo de rincones. Nos terminó con tres sistemas de gestión de la configuración, todos intrincadamente entretejidos en la lógica de negocio. Con una amplia reescritura, hemos sido capaces de 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 kloc 250, decidimos terminar nuestra relación con el proveedor de terceros y hacer que nuestra aplicación está sola. Comenzamos una reescritura masiva y, por primera vez, añadimos una base de datos real a nuestra aplicación. Porque teníamos líneas claras entre la información de streaming, almacenamiento de datos y la lógica de negocio, esto fue una integración prácticamente perfecta.

Ahora, acercándose a 500 klocs, nos estamos moviendo la aplicación de una arquitectura basada en red. No sólo la interfaz de usuario puede separar de la lógica de negocio en un equipo diferente, el cálculo real de las cotizaciones y órdenes que la aplicación envía a cabo será la carga equilibrada y hacia fuera para maximizar la eficiencia. Esto no sería posible sin una arquitectura de n niveles.

En cada etapa de crecimiento, estábamos bien con la ayuda de una separación limpia o impedida por nuestra propia confusión de la comunicación, los datos, los negocios y la interfaz de usuario. Probablemente no ha sido una preocupación más importante que la separación en la creación de esta aplicación.

Answer 2

Eso es una gran pregunta! Algo que todos los desarrolladores ASP.Net tiene que pensar. Es probable que obtener una gran cantidad de respuestas, me gustaría animar a estas ideas básicas de sentido común.

- Considere la simplicidad y rapidez de entrega como parte de una arquitectura de "éxito", no sólo "pureza". Trate de balancear entre sostener a los ideales arquitectónicos, y ser práctico.

- En general, parece que tiene sentido dividir el código a cabo en capas como usted menciona. Yo sugeriría sin embargo, que para la lógica específica de la página, que podrían quedarse en la página si es más fácil / más rápido - ¿por qué crear objetos de negocio genéricos de código que simplemente se utilizan 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 facilidad de mantenimiento

Hay muchos puristas en este sitio que les gusta hacer arquitectura para el sitio de la arquitectura - utilizar la arquitectura como una herramienta para ofrecer una solución a un problema de negocio, no sólo como una forma de arte por su propio bien, que sea una herramienta útil en lugar de que el uso de usted.

Answer 3

Mantener las preocupaciones por separado. Es muy muy importante. No mezcle con la interfaz de usuario y Biz Biz con capa de datos. Trabajar con la abstracción. Trabajando con la abstracción también hace que la prueba (prueba de la unidad) más fácil (burlarse de ellos). Yo sigo estrictamente cada capa que le corresponde. Recuerde que el costo más alto de cualquier proyecto es que es mantenimiento. Si se mezclan las preocupaciones continuación, mantenimiento va a convertirse en una pesadilla.

Answer 4

Tenemos una aplicación de Windows Forms, y una aplicación ASP.NET. Ambos utilizan el mismo proyecto Business Objects (alrededor de 140 clases).

El proyecto Winforms consta de alrededor de 350 clases de formulario y de control de usuario, y un muy pocos (<10) de estos necesita metadatos sobre sí mismos a partir de la base de datos.

El proyecto ASP.NET tiene cerca de 100 páginas .aspx.

Tenemos una capa de acceso de datos que consta de 5 clases, que se refieren a sí mismos con ADO.NET, hilos y transacciones. Convierten las peticiones de los objetos de negocio en llamadas SQL Server.

Las capas de interfaz de usuario (con la excepción de las pocas clases que necesitan metadatos acerca de la forma de exclusión molecular) hacen ningún acceso de base de datos en absoluto. Incluso las pocas excepciones pasan por el DAL como cualquier otra cosa.

La capa de negocios no sabe nada sobre el funcionamiento interno de la capa de acceso a datos, y cuando se necesita datos, sólo alguna vez llama a los métodos públicos en las clases DAL.

No estoy en absoluto un fundamentalista cuando se trata de este tipo de cosas, pero nunca he necesitado para cortar las esquinas en este caso.

Así que en resumen, 100% puro. Se trata simplemente de siempre funcionó mejor para hacerlo bien.

Nos gustaría tener un infierno de una buena razón para alejarse de esto ahora.

Answer 5

Code Monkeys y puristas son mucho como cualquier otro extremista en la vida.

Tenemos extrema derecha y extrema izquierda. Muy pocas personas son exactamente uno o el otro y se encuentran con un buen punto medio en el que se sientan. Si no fuera por los extremistas no sabríamos dónde están los límites.

En cuanto a la forma en que el código va. Escucho el camino puristas de hacerlo. Veo a los monos de código va sobre sus métodos. Yo uso mi experiencia para elegir un punto medio que me da la cantidad adecuada de flexibilidad y capacidad de gestión, junto con el tiempo que necesito para producirlo y la cantidad de dinero que realmente voy a conseguir para hacerlo.

Answer 6

Cuanto más grande sea el código, el más largo es el tiempo de vida, los más diferentes personas trabajan en el código (ambos al mismo tiempo o durante el tiempo de vida) que la separación más importante en capas es. En un principio, parece ser un poco más trabajo 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 jefe de programación o arquitecto técnico necesita buenas habilidades sociales, así como habilidades técnicas puras. Usted puede tratar de hacer cumplir la separación de vista técnico (véase más adelante), pero al final, es necesario convencer (o forzar) a los desarrolladores para mantener el cuadro grande limpio.

Pero esto no quiere decir que los medios técnicos para hacer cumplir la separación no tienen ningún uso. De hecho, he encontrado que asegurar que "transfronterizo llama" son algo difícil de hacer hará que la gente pasa más tiempo pensando en lo que realmente necesitan en el fronterizo interfaz de cruz, lo que lleva a las interfaces más limpias. No importa si la dificultad es técnico (ya que hay que utilizar COM o CORBA) o alguna otra cosa (que tiene que llenar un formulario de la página 7 por triplicado).