tag route page net asp asp.net asp.net-mvc architecture loose-coupling

asp.net - route - ¿Por qué debería una arquitectura web estar acoplada libremente?



asp route tag helper (13)

Creo que la forma "correcta" se explicó en las otras respuestas. Pero ahora escribiré desde mi propia experiencia.

Hay algunas cosas que debe tener en cuenta al decidir una arquitectura.

a. Cliente

¿Tienes suficiente tiempo para hacer todo de la manera "correcta" (excelente arquitectura, pruebas, etc.)? A veces el cliente quiere ver resultados rápidamente. Podemos quejarnos de que el tiempo es corto y que el producto no estará en los estándares más altos, pero al final ese es nuestro problema. En estas situaciones, le explicamos al cliente lo que obtendrá y escribimos el código de espagueti que todos conocemos.

¿Cuáles son los requisitos de los clientes (en términos de confiabilidad, escalabilidad, capacidad de expansión, velocidad)? Creo que esto se explica por sí mismo. A veces el cliente dicta la manera "correcta". Podemos ofrecer al cliente la forma "correcta", pero al final el cliente decidirá (dependiendo del tiempo y el dinero, por supuesto).

¿Quién apoyará el sistema después de que lo hayas desarrollado? Me gustaría apoyar un código agradable y desacoplado. Así que cuando escribo el código, doy lo mejor de mí para hacerlo "correcto". En algún momento podría acoplar la vista y el controlador o acoplar algún servicio y estar contento con ello. Saber mi propio código es fácil soportarlo.

segundo. Proyecto

¿Cuál es el tamaño del proyecto? Algunos proyectos son tan pequeños que no se justifica ninguna arquitectura complicada.

¿Existe alguna posibilidad de que el software crezca rápidamente en el futuro (más funciones)? Este es uno de los mayores retos. Pero si el software crece, significa que es un éxito. Probablemente tendría más recursos para trabajar. Es relativamente fácil refactorizar su código y hacerlo "correcto".

¿El proyecto potencialmente tendrá problemas de escalabilidad? Hay proyectos que nunca van a crecer, en términos de usuarios y datos. He visto proyectos que intentan parecer serios utilizando una configuración de base de datos de Oracle RAC, ¡cuando una simple base de datos integrada funcionaría bien!

¿Comenzaste el proyecto o lo estás tomando de otros desarrolladores? Esta es una combinación de las preguntas de quién apoyará el software y cómo crecerá el software. Puede obtener un código espagueti de otros desarrolladores. ¿Tendrá el tiempo y los recursos para hacerlo "correcto"?

do. Equipo de desarrollo

¿Tiene el equipo suficiente experiencia para hacer el desacoplamiento correcto? Cuando tenía menos experiencia, intenté escribir el código "correcto". Y he fallado. El punto es conocer realmente a su equipo de desarrollo, sus habilidades y conocimientos. No subestimes este problema. Cuando trabajo con desarrolladores menos experimentados, normalmente hago algunos sacrificios a la arquitectura. El sacrificio que se hará es la conjetura mejor educada que tengo. Hay algunos puntos de la arquitectura que puedes sacrificar y hay algunos que no puedes. Por lo general, uno o más sacrificios que has hecho antes volverán y te mordirán.

¿Los desarrolladores tienen experiencia escribiendo pruebas automáticas? No es suficiente tener pruebas automáticas. Deben estar completos (tanto como sea posible) y hacerse bien. Si tus pruebas son débiles, mejor que no las tengas. No querrías apoyarte en una pared llena de agujeros.

Conclusión :

Sé que todos queremos ser profesionales. Y como profesionales debemos tener todo en cuenta. No podemos perder nuestro tiempo y energía haciendo las cosas de la manera "correcta". A veces debemos mirar otros factores (la realidad) y hacer nuestra elección. Y lo más importante es vivir con ello.

Cuando miro los proyectos MVC de ASP.NET, cada vez veo una arquitectura acoplada suelta.

¿Para qué necesito un acoplamiento suelto en una arquitectura web (si no hago pruebas unitarias)?

¿Cuáles son las ventajas y desventajas de esto?

¿Cuál es la razón principal para desacoplar capas / clases?

¿Qué pasa si no quiero cambiar mi DAL por ejemplo? Quiero decir, ¿cuándo debo cambiar mi DAL completo? Así que podría acoplar mi DAL a la interfaz de usuario. ¿Qué hay de malo con esto?

División del trabajo, que es el equivalente humano de la separación de preocupaciones. Tu gurú de HTML debería poder trabajar independientemente de tu diosa SQL.

Un cambio dramático en el extremo delantero debería poder continuar sin desgarrar el backend, y viceversa. En otras palabras, solo deberías contratar a una persona en lugar de dos.

En el papel, hay muchas ventajas de acoplamiento suelto, pero en la práctica, es difícil hacerlo bien en mi humilde opinión. Aquí hay algunas ventajas:

  • Los sistemas pueden evolucionar independientemente en términos de ciclo de vida.

  • Los sistemas pueden escribirse en diferentes idiomas y, en última instancia, ejecutarse en diferentes sistemas operativos.

  • Los sistemas pueden (y deben) ser construidos por diferentes equipos. Puede externalizar el desarrollo de sistemas. De hecho, esta es casi la única forma de escalar una organización de desarrollo de software.

Aquí hay algunas desventajas sin embargo:

  • Es más trabajo al principio, y si no lo haces bien, es posible que nunca veas los beneficios de ello.

  • La definición de API / Contratos es bastante difícil y requiere desarrolladores con mucha experiencia. Es fácil de hacer inicialmente, pero es difícil a largo plazo.

  • La generalización de los acoplamientos sueltos puede, de hecho, conducir a la escritura floja en todas partes. En lugar de usar objetos significativos claramente definidos, puede observar un aumento en el uso de los parámetros de "objeto" o tipo de retorno, de los tipos genéricos agregados a cada clase o interfaz. El efecto negativo de esto es que el desarrollador promedio probablemente agregará operaciones de lanzamiento salvaje en todas partes, asumiendo tipos en ambos lados de los llamados sistemas de acoplamiento libre.

  • Algunas técnicas de acoplamiento flexible se basan en la generalización de la definición de interfaces, con la intención de evitar la dependencia directa. Recuerde que una interfaz debe estar tallada en piedra una vez definida y publicada. Ahora, eso no es realmente lo que yo llamo acoplamiento suelto. Una clase .NET, aprovechando el JIT y técnicas como la sobrecarga de métodos puede ser un mejor instrumento de acoplamiento suelto. Entonces, el problema con estas interfaces y fábricas en todas partes es que conducirá a una multiplicación de tipos, ensamblajes, casos de prueba, etc ... y simplemente más trabajo y complejidad en el futuro. En lugar de simplificar las cosas, en lugar de construir un sistema, tendrás que construir muchos. "Un sistema de N niveles es N-veces el trabajo" :-)

  • El acoplamiento suelto de alguna manera pasa por alto una de las herramientas más poderosas jamás creada: el compilador (C # u otros). Y ese es todo el propósito de la realidad, pero definitivamente tiene algunos inconvenientes porque todo el trabajo de campo que estaba haciendo el compilador (verificación de tipos, etc.) tendrá que hacerse en otra parte (pruebas), y eso tendrá un costo.

  • Es probable que muchas herramientas listas para usar no funcionen más. No podrá usar cosas como Visual Studio "Ir a la definición" o "Buscar todas las referencias".

En primer lugar, deberías estar escribiendo pruebas unitarias;)

Digamos que terminas necesitando cambiar la base de datos subyacente. Si su código de acceso a datos está estrechamente unido a su lógica de negocios, esto podría ser un gran esfuerzo. Con el código acoplado de forma flexible, su lógica de negocios no se verá afectada.

¿Qué sucede si decide que desea escribir algunas utilidades de línea de comandos que aprovechan sus componentes de back-end? Proporcionar múltiples puntos de entrada a su sistema es mucho más fácil de lograr con un código débilmente acoplado.

La razón principal para acoplar y desacoplar las clases es la extensibilidad. El cambio en uno no debe afectar al otro.

si creas una aplicación que actualmente está utilizando la base de datos MYSql para almacenar los datos. Ahora tenemos un nuevo requisito para almacenar los datos en MSSQL como su sistema backend. ¿Qué solución te queda si construyes el sistema más integrado con las bibliotecas MYSQL? Para reescribir la aplicación completa para MSSQL. Ahora, ¿qué tal esto? Construimos un nuevo DAL basado en MSSQL y conectamos el Dal en el sistema sin realizar ningún cambio en el sistema (UI).

La aplicación está llamando a la rutina basada en interfaces y las interfaces están libres de implementación.

Trate de leer acerca de Unity o MEF. Estos temas le brindarán una buena perspectiva.

Le ahorrará mucho tiempo para cualquier proyecto que no sea trivialmente pequeño, donde lo defino trivialmente pequeño como menos de un par de miles de líneas de código (según el idioma).

La razón es que una vez que superas proyectos super pequeños, cada cambio o actualización se vuelve más difícil cuanto más estrechamente acoplados están. Estar acoplado de manera flexible le permite seguir avanzando, agregando funciones, corrigiendo errores, etc.

En un momento dado, creo que cualquier programa se convierte en una pesadilla para mantener, actualizar y agregar. Cuanto más débilmente acoplado esté el diseño, más se retrasará ese punto. Si está estrechamente acoplado, tal vez después de unas 10.000 líneas de código no se pueda mantener, agregar algunas funciones se vuelve imposible sin volver a escribir desde cero.

Estar acoplado de manera flexible le permite crecer hasta 1,000,000 - 10,000,000 líneas de código mientras que aún puede hacer cambios y agregar nuevas funciones dentro de un tiempo razonable.

Estos números no deben tomarse literalmente, ya que están inventados, sino para dar una idea de dónde se vuelve útil.

Si nunca necesita actualizar el programa y es bastante simple, entonces está bien estar bien acoplado. Incluso está bien comenzar de esa manera, pero sepa cuándo es el momento de separar las cosas, pero aún necesita experiencia en la escritura de código acoplado de manera flexible para saber en qué momento se convierte en beneficioso.

Enterprise Fizzbuzz es un ejemplo intencionalmente humorístico de cómo es posible excederse con la sobreingeniería, y no todos los proyectos van a necesitar el mismo nivel de desacoplamiento.

En general, se considera que MVC es un buen punto de partida porque la mayoría de los proyectos serán lo suficientemente grandes para que sea útil. Cuando el proyecto crece, ese nivel de desacoplamiento no es suficiente y la parte M debe dividirse en varias capas, y así sucesivamente. No hay una talla única para todos, pero MVC es una buena cantidad de desacoplamiento para la mayoría de los proyectos.

Loose Coupling le permite hacer cambios en un área de la aplicación sin afectar a las otras. Teóricamente, le permite hacer cosas como cambiar su capa de acceso a datos sin reconstruir sus capas de negocio o UI.

Definitivamente hace que sus aplicaciones sean más flexibles, más adeptas al cambio y más fáciles de mantener (ya que no tiene que preocuparse por un cambio en un área de la aplicación que rompe otra).

Porque las cosas en la parte posterior pueden ser útiles incluso si no se está comunicando con una interfaz de usuario web HTTP basada en el navegador. Así que quieres poder desconectarlo de esa IU en particular.

Respondiendo con un ángulo que nadie más discutió; desacoplamiento temporal . Se puede hacer de varias maneras:

Al usar lo anterior (excepto la mónada asíncrona), a menudo trata los mensajes explícitamente en lugar de invocaciones de métodos. Esto lleva a pensar cómo se correlaciona con la forma en que funciona el paso de mensajes (idempotencia de manejo, colas para almacenarlos en tránsito, datos de seguridad adjuntos a sus sobres, reintento de la lógica en los manejadores en lugar de solicitantes, ...).

Al avanzar hacia arquitecturas orientadas a mensajes que están temporalmente desacopladas, puede hacer que sea más fácil extender la aplicación, especialmente si la mayoría está haciendo publicaciones de suscripción (vea también, arquitectura dirigida por eventos), cualquier cosa puede escuchar los eventos y reaccionar ante ellos. no vincule las implementaciones de integradores a los sitios de llamadas iniciales.

Los sitios web que empujan el trabajo a las colas son más receptivos en general, porque no permiten que los hilos de los trabajadores se queden esperando a que suceda el IO. También suelen ser más baratos de mantener a largo plazo.

Para diferentes tipos de acoplamiento de tipo compilación (y otras métricas), navegue por http://www.ndepend.com/Metrics.aspx y lea un poco sobre esto.

Te dará escalabilidad. Por ejemplo, si tiene una capa de servicio detrás, puede separarla en varios servidores. Además tendrás menos dependencias y las modificaciones serán más fáciles. También el soporte de código será más fácil.

Aquí puede ver un artículo pequeño e interesante: SOA - Acoplado libremente ... ¿Qué?

En breve dice:

Los sistemas débilmente acoplados ofrecen muchas ventajas, incluido el soporte para la vinculación tardía o dinámica a otros componentes durante la ejecución, y pueden mediar la diferencia en la estructura del componente, el modelo de seguridad, los protocolos y la semántica, lo que reduce la volatilidad ...

Todo depende de la intención de hacer la Aplicación junto con el interés comercial. Si el negocio está dispuesto a escalarlo y hay suficiente combustible (lea el corpus), esto le da al arquitecto lo suficiente como para que la aplicación obtenga beneficios a largo plazo.

Así que las ventajas son: -

1) Si está utilizando un código / control de terceros: escriba siempre una "capa de envoltura / adaptador" para que por alguna razón, si no es posible, pueda obtener otra cosa y cambiar la capa del adaptador sin alterar el código del repositorio de la aplicación.

2) Encapsular funcionalidades complejas específicas en una "capa de servicio" que puede o no requerir solicitudes de base de datos: es beneficioso porque la solicitud y la respuesta siguen siendo las mismas (seguramente también puede cambiar con el tiempo), siempre puede trabajar en el rendimiento de ese código específico sin cambiar la salida. Con las unidades de unidades en su lugar, también podemos medir el rendimiento del código.

3) Crear roles específicos escriba un código específico: si creamos muchos roles, es más fácil para las personas del equipo enfocarse en su repositorio específico en lugar de perdernos en la pila de código no relacionado.

4) Control de calidad enfocado: si tenemos una arquitectura de capas, siempre ayuda a mejorar el control de calidad como su enfoque.

5) Búsqueda / resolución de errores: Al usar la arquitectura en capas y suponiendo que tiene un buen registro en su lugar, siempre ahorra tiempo para encontrar los errores y resolverlos.

Las desventajas son: -

1) La configuración de una aplicación con este tipo de marco tomará tiempo adicional. Así que "ir al mercado" se retrasará.

2) Si te entusiasma demasiado la tecnología, podría acabar matando.

3) Latencia de transacción adicional: a medida que los datos viajan a través de varias capas, existe una latencia adicional que se agrega en cada transacción.

Sobre cambiar el DAL: -

Por supuesto, habrá un momento en el que el rendimiento tendrá prioridad sobre las características en ese momento en el que tendrá que comenzar a considerar a sus proveedores de datos que conduzcan al cambio en DAL.

Si acopla su DAL a su interfaz de usuario, cada vez que cambie su DAL (si es que lo hace, siempre que sea necesario), siempre deberá relanzar todos los archivos binarios en producción. El cual tiene su propio conjunto de problemas (no puedo explicarlo aquí, si lo requiere, siempre puedo incluirlo)

Esa es la razón, inicialmente siempre es mejor pasar el tiempo y concluir cuándo ocurrirá el "autodestrucción" para la aplicación. Me refiero a lo que es la vida de la Aplicación, si esto se responde bien, descanse, todo caerá en su lugar.

Una arquitectura débilmente acoplada lo ayudará cuando su aplicación necesite cambiar o crecer. Y cualquier aplicación no trivial eventualmente tendrá que cambiar o crecer.

Si diseña con una arquitectura poco acoplada, solo se verán afectadas algunas partes de la aplicación cuando cambien los requisitos. Con una arquitectura acoplada demasiado apretada, muchas partes necesitarán cambiar, y será difícil identificar exactamente qué partes se verán afectadas.

Uno de los principales beneficios de TDD, en mi opinión, es que ayuda a promover una arquitectura débilmente acoplada.

Ventajas:

  • Escalabilidad: le permite expandir una capa de acceso a la base de datos
  • Intercambiabilidad - por ejemplo, código de proveedor de correo electrónico
  • Mantenibilidad - solo cambia el código en un solo lugar
  • Facilidad de configurar la prueba unitaria: puede simular objetos como su base de datos

Desventajas:

  • Varias líneas extra de código tal vez
  • Algunas clases de interfaz extra