How to restrict the violation of an N-Tier Architecture

Question

Recently we fitted a 4-Tier Architecture in our project composed by the following four main layers :

• User Interface Layer.
• Data Access Layer.
• Domain Layer.
• Business Layer.

All the layers fulfill their usual roles in 4-Tier Architecture and interact which each one in the usual way. We use SVN to maintain our CVS.

My problem is that we have many inexperienced programmers developing in a well formed architecture, and we have to be checking all the time the code to find violations of the architecture.

For example:

• Sometimes include access to database in the User Interface Layer and not in the Business Layer which is where interact with the Data Access layer to read or save data in the database.

Problems like the above occurs all the time. My question is:

How to check the code before the programmers can submit his new changes to the repository and report violations of the architecture? How to avoid doing this manually?

Answer 1

Perhaps what you're attempting is possible with Layer Diagrams.

See MSDN: Validate Code with Layer Diagrams

To make sure that code doesn't conflict with its design, validate your code with layer diagrams in Visual Studio Ultimate and Visual Studio Premium. This can help you:

• Find conflicts between dependencies in your code and dependencies on the layer diagram.
• Find dependencies that might be affected by proposed changes. For example, you can edit the layer diagram to show potential architecture changes and then validate the code to see the affected dependencies.
• Refactor or migrate code to a different design.
• Find code or dependencies that require work when you move the code to a different architecture.

You can validate code manually from an open layer diagram in Visual Studio or from a command prompt. You can also validate code automatically when running local builds or Team Foundation Build.

or Channel 9: Using layer diagrams to design and validate your architecture

This short video shows how to design architectural layers in your product, and then validate them to ensure that components implement the intended architecture.

Answer 2

If the UI layer has no access to the assemblies or authentication information needed to access the database, it is impossible to access the database directly from that layer. If you have separated your layers into separate assemblies, and limit the public data types and members to only those needed in the higher level layer, it is easy to detect a violation, as an assembly reference will have been added.

One problem pointed out by the user Euphoric below is that the assembly restrictions do not prevent lower layers from making calls into higher layers using interfaces, events, or delegate callbacks. So education about layering is still needed.

Answer 3

There is only way to solve this problem: tutoring and core reviews. It is no-brainer that inexperienced developer's code is first reviewed by more experienced one before it is checked in. The reviewer then provides feedback, so the developer can fix the code and learn not to do same mistake again. And if said developer repeat same mistakes all the time, then it is time to look for a new developer.