Question

As a learning exercise on software architecture (and also on Visual Studio), I decided to create a set of four minimal WPF/C# applications (solutions) with a single purpose: read some circle parameters from file when a button is pressed, and display the result on the GUI:

1. One application reads from .txt file and displays the parameters in a textbox;
2. One application reads from .xml file and displays the circle in a canvas;
3. One application reads from .txt and displays the circle;
4. One application reads from .xml and displays the text parameters;

That is, I have one Domain project containing a Circle class, two DataAccess projects (one for xml and other for txt), and two presentation projects (one for geometry drawing, and other for displaying text). Each of the four solutions refers to a combination of these reusable, modularized projects.

Also, I’d like to use the FAÇADE design pattern, so that the Presentations “see” the façade but not data-access or domain. The Façade sees the Domain and the DataAccess, and each DataAccess just do their business blindly.

THE PROBLEMS are these:

• I needed two Façades, because I have to create a namespace dependency to one of the two DataAccess layers in order to use the DataAccess namespace inside the Façade project. So one Façade depends on the XmlBackend, and other depends on TxtBackend;
• Each Presentation depends on the Façade so that the namespaces are available, but SINCE I HAVE TWO FAÇADES, each Presentation project would end up depending on two different Façade projects, which is a Bad Thing;

I tried to create a single Façade project, so that each Presentation would refer to it, but then this Façade would depend on two different DataAccess backends. Then in a solution, I could not have only one DataAccess backend project, because the Façade project would depend on two different ones.

So the question is: How I could resolve this so that I can have four solutions, each solution having only the necessary projects (the domain, the façade, one presentation and one data backend), the layering architecture not being violated, and each project not needing to know too much about the others?

Update: the Msdn Library says the folling, which I think might be a hint: “[solution explorer allows you to] add items that are useful to multiple projects in the solution or to the solution without referencing the item in each project.”

Thanks for reading!

Answer 1

If you want full decoupling and absolutely need the Façade to be reusable independently from the two DataAccess modules, you could have the Façade layer declare an IDataAccess interface that classes in both DataAccess projects would implement.

A third party module (one of the GUI’s ?) would then inject the correct DataAccess concrete implementation into the Façade as needed at runtime.

As a side note, part of your problem comes from the fact that in this architecture, 1 project pretty much == 1 class, so object tight coupling and project tight coupling concerns are mixed up.

However, you should note that object tight coupling leads to fragility, poor maintainability and testability while project coupling only affects reusability. In other words, you could live with Façade referencing both DataAccess projects, it would only mean that you can’t reuse Façade in another context/architecture without the DataAccess projects somewhere at hand.