Dependencias cíclicas - una vez más

Question

Estoy luchando para evitar dependencias cíclicas. Sé que necesito ocultar la implementación con interfaces, pero ¿cómo manejo una situación con dos ensamblajes, donde cada uno necesita crear instancias de clases desde el otro o llamar a un método estático desde allí?

Editar:

entiendo esto se puede solucionar mediante el uso de un solo montaje. Tenemos más de uno por el siguiente motivo:

• Nuestro "sistema" se compone de varios componentes. Un cliente puede tener solo un componente, o más, así que lo que hicimos fue crear diferentes ensambles para diferentes componentes. Tiene sentido, ¿por qué desplegarías cosas que no necesitas? ¿No es una pérdida de memoria?
• cosas que eran comunes a más componentes, principalmente clases de ayuda, fueron a otro ensamblado - una vez más no todos los componentes necesitan todas las clases auxiliares, entonces hay más ensambles
• sin embargo, estas dos aplicaciones pueden comunicarse entre sí - el sistema para los médicos envía solicitudes al sistema para las enfermeras, las solicitudes van a volver, etc. - y aquí es donde el problema real es

Tener los dos componentes que hablan entre sí en realidad es sólo una de las situaciones que hemos tenido una dependencia cíclica entra en conflicto antes. Ocurre de vez en cuando y, cuando sucede, necesitamos resolver cómo resolverlo, mover algunas clases y, a veces, necesitamos agregar un nuevo ensamblaje.

Ahora tenemos como 8-10 ensamblajes, y parece que cuanto más tenga, más rápido se agregarán :) - por ejemplo, agregamos una función de propósito general que usa atributos personalizados - así que agregamos otro ensamblaje solo para el atributo - en caso de que no entre en conflicto en el futuro

¿Es este el camino a seguir? Realmente siento que estamos haciendo algo fundamentalmente erróneo :)

Realmente agradezco su opinión.

Answer 1

Intentaré sacar los tipos ofensivos en un tercer conjunto "común" al que hacen referencia los dos ensambles "principales".

Me gustaría preguntar por qué necesita varios conjuntos en primer lugar, sin embargo, cuando ambos dependen el uno del otro. Los ensamblados son unidades de implementación y se pueden versionar por separado. Si no necesita esta funcionalidad, simplemente empacaré todo en un solo ensamblaje y terminaré con eso. Esto tiene las ventajas adicionales de acelerar la construcción y simplificar la implementación.

Intente agregar más contexto a su pregunta; tal vez haya algunos detalles que podamos ayudar si sabemos exactamente qué es lo que está tratando de hacer.

Editar re sus adiciones: Para responder específicamente a su pregunta acerca de si o no varios ensamblados está el camino a seguir, considere esto: Una vez trabajé en una base de código como este con Visual Studio 2008, donde había alrededor de 20 por separado los archivos del proyecto se abren en la solución de una vez. Estos 20 proyectos fueron todos compatibles con archivos DLL para un único EXE principal. Estos proyectos no se compartieron con otros productos, ni hubo requisitos de versiones extraños.

Trabajar con esta solución fue una pesadilla. Tomó literalmente 5 minutos para que Visual Studio compilara la solución. La compilación en la línea de comandos con MSBuild tomó 2 minutos. Esto hizo que los cambios incrementales fueran un ejercicio de frustración y dolor. Dado que todos los proyectos se usaron en la fabricación del ejecutable principal, ninguno de ellos se pudo descargar para acelerar la compilación, y hubo un mandato ejecutivo para no dividir los proyectos en soluciones separadas.

Si termina con una sola solución como esta, créame cuando digo que usted y sus compañeros se rebelarán algún día ... Mi recomendación sería dividir los ensamblajes en sus propias soluciones, agrupando los ensamblajes que es probable que cambien juntos; luego, cree una tarea de compilación personalizada que copie el ensamblaje final en una carpeta común desde la cual todos los demás ensamblajes puedan tomar referencias.

Answer 2

¿Puedes poner las cosas en común en su propio ensamblaje?

Estoy de acuerdo con un comentarista que probablemente necesitemos más información.

¿Por qué tiene 2 conjuntos?

¿Hay alguna razón por la que no todo esté en un ensamblaje?

¿Cómo se conectan estos conjuntos? ¿Solo por referencia o hay componentes WCF, etc. involucrados?

Le hemos dado las respuestas más simples, pero tal vez hay más que lo que podemos decir por su breve descripción.

Answer 3

Una forma de evitarlo sería utilizar una estructura proxy/comercial.

AssemblyA.Proxy - contiene dos clases: una interfaz (vamos a llamarlo iServices), y otra clase responsable de llamar AssemblyA.Business métodos.

AssemblyA.Business - contiene una clase, que implementa los métodos declarados en iServices.

AssemblyB.Proxy - analógica a AssemblyA.Proxy

AssemblyB.Business - analógica a AssemblyA.Business

De esta manera, cada componente proxy sólo se haría referencia a la lógica de negocio que se supone a. AssemblyA.Proxy tendría una referencia a AssemblyA.Business; AssemblyB.Proxy tendría una referencia a AssemblyB.Business. AssemblyA.Business haría referencia a AssemblyB.Proxy, y así sucesivamente.

No sé si está claro, pero espero que ayude.