How to check application for compliance with layer architecture

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

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

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



    Inside the command, the order of calls is obvious to everyone, and that the interface should not directly access the database layer. When you have three builds in a project, this will probably not be a problem. But when you have ten of them, it will become difficult to keep in mind who will whom and from which layer can cause. Therefore, we will document our scheme by adding a Modeling project (File / Add New Project / Modeling Projects / Modeling Project) to the Solution:



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



    Let's consciously make a logical mistake in the architecture 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 challenge with hundreds of commits per week. But gradually, your decision will turn into a mess. What to do?

    Create a mapping of layers to assemblies.



    In fact, we still have to go one step after the main components of the system are created in the form of assemblies and a layer diagram is drawn. You need to compare them with each other by simply dragging the project nodes from Solution Explorer onto the rectangles of the layers:



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



    Now everything is ready for automatic architecture verification, just call the context menu on the layer diagram:



    After a short analysis, which works through Reflection, we get a list of inconsistencies of our code with the architecture:



    And there will be the very call that we are conscious of They made a good contribution 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 the refactoring (in our simple case, just transfer the call from the UI to Business Logic), the architecture will validate lead to such results:



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

    Also popular now: