How to check the application for compliance with the architecture of layers

Any developer knows the architectural pattern of the layers. With all its straightforwardness, it allows you to effectively hide the implementation and abstract components of different levels. Layers of the lower level can be changed without much risk to spoil the operation of the application, refactoring is facilitated. The only obvious condition you must comply with is to adhere to the accepted architecture. But sometimes it happens that a programmer is no-no and is tempted to call a couple of methods “through the head”. For example, from the interface layer go straight to the database layer. We will not look here for malicious intent, maybe this case was associated with haste with the release of an urgent fix for the customer. But gradually the number of such small “sins” can nullify the once adopted harmonious architecture and you will again find yourself with “spaghetti code”. It may be very difficult to catch such cases of code mismatch with the architecture of layers on a large system. Fortunately, Visual Studio 2010 (Premium and Ultimate editions) has tools that can make this task much easier.

In Visual Studio 2010 there is a component called Layered Diagrams - layer diagrams. At first glance, this is a banal drawing tool "cubes". The remarkable thing about it is that later you can match the assemblies of your project to specific layers, and automatically check if there are any calls that contradict the accepted architecture among the application code.

Let's look at a simple example. Suppose we have a classic three-tier application with an interface, a layer of business logic and a database layer.


')
Inside the command, the order of calls is obvious to everyone, and that one should not refer directly to the DB layer from the interface. When you have three builds in a project, this may not be a problem. But when there are about ten of them in you, it will be difficult to keep in your head who and from what layer can cause. Therefore, we will document our scheme by adding a project with the Modeling type to the Solution (File / Add New Project / Modeling Projects / Modeling Project):



Next, add a layer diagram (Add New Item / Layer Diagram) and draw our layer architecture:



Let's consciously admit a logical error in the architecture of layers right in the code. Add a reference to DbLayer and call it directly from UILayer:



If you have a complex system, it can be very difficult to detect such a call with hundreds of commits per week. But gradually your decision will turn into a mess. What to do?

Create a juxtaposition of layers to assemblies.

In fact, it remains for us to do one more step after the main components of the system are created in the form of assemblies and the diagram of layers is drawn. It is necessary to compare them with each other simply by dragging project nodes from the Solution Explorer onto the layer rectangles:



In this case, the number of assemblies associated with this layer will be displayed in the upper right corner, and in the Modeling project, links to the solution components will appear:



Now everything is ready for automatic verification of the architecture, it is enough to call the context menu on the layer diagram:



After a brief analysis that works through Reflection, we get a list of inconsistencies of our code architecture:



And there will be the same challenge that we deliberately added to the code, which runs counter to the current architecture of the solution:

Error 1 AV0001: Invalid Dependency: UILayer.MainWindow.CalculateDiscount_Click (Method) -> DbLayer.Customer.IsHabraUser (Field)

After you do refactoring (in our simple case, just transfer the call from the UI to Business Logic), the validation of the architecture will produce the following results:



What tells us that the code of our solution is fully consistent with the adopted architecture of the layers. If necessary, you can configure the verification of compliance of the code with the architecture of layers in automatic mode, for example, when building a project in TFS using MSBuild (in Russian).