Automatic control of architecture in Visual Studio

As you do not know, but I recognized myself in this picture. You see, when an application architecture is designed, everything is beautiful, logical and corresponds to the best international practices. But in the process of work, when faced with the limitations imposed by the architecture, we often think: “I’m breaking a little here, this will save me an hour of development time. Well, then, as time will be, I will correct it. ” But, for some reason, this time never comes. In my opinion, the only way to force yourself, as a programmer, to follow the developed architecture, is to teach the development environment to show all deviations and crutches as compilation errors. In this case, if the code is bad, it will immediately be fixed, but if the architecture is outdated, then it will be fixed. Those. in the code storage will always be the code corresponding to the planned architecture.
A couple of words about what will be rolled up:
1. A small preamble.
2. Restoration of the architecture of the existing project.
3. Configure Visual Studio and TFS to automatically control the architecture.
There are a lot of pictures under the cut and the desire to try everything described.

So, the promised preamble. Almost a year ago, Dmitry Andreev ( dmandreev ) already published an article on this topic. I read this article with great pleasure, and, in fact, it was she who prompted me to address the issue of applying the Layer Diagram in the application development process. By the way, having read this far, have you already gone over the above link and read what Dmitry has written? No, well then, let me wait for you, and then we go on. I am waiting.
Ok, now that you and I have a common understanding of the Layer Diagram, you can finish with the preamble and move on to practical work.

Preparation of a demonstration project

To demonstrate the work with the Layer Diagram, I will take a project a little closer to reality than Dmitry considered. Let us have a data access layer (I will use the Entity Framework) and, in fact, a layer of client applications which will also have a layered structure (MVVM). At the client level, the model will be taken from the first layer, but the View and ViewModel layers will be spread over several assemblies.
So, these four projects look after creation:

I think everything changes the default Namespace for the assemblies being created? Well, in this example, for 3 client builds, I will replace the Default Namespace:

Add a database and an Entity Model to the DAL project. In client projects, we create the View and ViewModel folders. Add test components and classes to them:

Adding links between projects, references between the created components and classes, you can get a dependency graph of the following form:

If splitting into layers goes at the level of assemblies, then due to the prohibition of cyclic references between assemblies (otherwise it is impossible to determine the order of construction), only the problem of “circulation through the layer” (which is just considered in Dmitry’s article) is possible. If in the project, as in this case, the layers are spread over several assemblies, and within the same assembly there are representatives of different layers, dragging projects / files from the Solution Explorer into the Layer Diagram is not effective. And here comes Architecture Explorer, which is called from the main menu: Architecture -> Windows -> Architecture Explorer. Immediately after opening it will look like:

Frankly, when I read about this tool for the first time, I immediately fell in love with it. Such opportunities for analyzing dependencies, which is simply breathtaking. And although you can write about him a lot and enthusiastically, as he does not allow to automatically control the architecture, more about him in another time.

Restore layer diagrams from solution artifacts

Once the scene is ready, we release the actors. Add a model project to the solution, add a Layer Diagram to it already:

Yes, here we can drag layers out of the Toolbox, draw dependencies, then transfer classes from client projects to the layers for a long time and hard. And all this only so that the next day, when the developer adds a new class, about which we do not know, and it is not tied to the layers, and therefore the test will stop working. To avoid this, we need the Architecture Explorer.

Please note that all the ViewModel classes are in the same namespace (well, let it be in 3-5 in the real project), and we can now add to the layer diagram not classes, but the entire namespace. Select them and, without creating any layers, drag them to our Layer Diagram:

By the way, we can use the drag and drop functionality of projects from the Solution Explorer. With Shift, we select ClientApp1, ClientApp2 and Base.Library in it, grab the left mouse button and drag it to the free space in the Layer Diagram:

Rename the new layer to Presentation, select two layers (View and View Model) and drag them to the Presentation layer:

Almost everything is ready, lacking only links. To generate them, just call the context menu on the Layer Diagram and select the Generate Dependencies option:

Now, our diagram of layers has taken the finished form:

If you have a question about the arrow from ViewModel to View, then you can look at the opinions on this topic, or maybe take part in the discussion, on the MSDN forum .

Automatic architecture control

Well, and the last moment, how to make the layer diagram automatically, at every construction, check that the code corresponds to the architecture? In fact, quite simple. For demonstration, I’ll add a component to ClientApp1, which will directly access the data access layer:

Run the build and see: Build succeeded. In order for builds to fail during architecture errors, you must open the model properties from Solution Explorer (via the context menu or select and press F4) and enable the architecture check:

Once again, we run the construction and see that we have architecture errors:

Double click on the error, immediately drive to the place where the crutch is clogged.
Of course, dependency checking leads to an increase in compilation time, so you can build two solutions, one with which the developers work (do not include the Modeling Project), and the second, with the same set of projects and the Modeling Project, for automatic builds in Team Foundation Server. In this case, at workplaces, construction is faster, and the architecture is monitored on the server, and, due to construction errors, bugs can be generated immediately.
Before proceeding to the conclusions, a small remark. Everything described in this article works in both Visual Studio 2010 and Visual Studio 2012. The only thing required is a version of Ultimate or Premium. If you do not have a license for the appropriate version of Visual Studio 2010, then the Release Candidate version of Visual Studio 2012 Ultimate can be downloaded here .

findings

1. Layer Diagram is a toolkit, about which you should at least know, and start to apply in new projects
2. Automatic architecture check will reduce the number of "crutches" hammered in a hurry or for not knowing
3. Proper namespace naming and use of the Architecture Explorer can significantly reduce the time to restore the architecture.
Ps If in this article I forgot to tell you about something, then please do not swear at me much, and read the original sources: Visualization of the existing code .