Restrict violation of architecture - asp.net MVP

Question

If we had a defined hierarchy in an application. For ex a 3 - tier architecture, how do we restrict subsequent developers from violating the norms?

For ex, in case of MVP (not asp.net MVC) architecture, the presenter should always bind the model and view. This helps in writing proper unit test programs. However, we had instances where people directly imported the model in view and called the functions violating the norms and hence the test cases couldn't be written properly.

Is there a way we can restrict which classes are allowed to inherit from a set of classes? I am looking at various possibilities, including adopting a different design pattern, however a new approach should be worth the code change involved.

Birkenhead

Answer 1

I'm afraid this is not possible. We tried to achieve this with the help of attributes and we didn't succeed. You may want to refer to my past post on SO.

The best you can do is keep checking your assemblies with NDepend. NDepend shows you dependancy diagram of assemblies in your project and you can immediately track the violations and take actions reactively.

_{(source: ndepend.com)}

Helles

@this.__curious_geek: thanks for pointing me to NDepend. I shall check it out. Cool nick btw.. – Birkenhead

Could you please answer #8852433 ? – Headreach

Answer 2

It's been almost 3 years since I posted this question. I must say that I have tried exploring this despite the brilliant answers here. Some of the lessons I've learnt so far -

1. More code smell come out by looking at the consumers (Unit tests are best place to look, if you have them).

   • Number of parameters in a constructor are a direct indication of number of dependencies. Too many dependencies => Class is doing too much.
   • Number of (public) methods in a class
   • Setup of unit tests will almost always give this away

2. Code deteriorates over time, unless there is a focused effort to clear technical debt, and refactoring. This is true irrespective of the language.

3. Tools can help only to an extent. But a combination of tools and tests often give enough hints on various smells. It takes a bit of experience to catch them in a timely fashion, particularly to understand each smell's significance and impact.

Birkenhead

Answer 3

What about NetArchTest, which is inspired by ArchUnit?

Example:

// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("NetArchTest.SampleLibrary.Presentation")
    .ShouldNot()
    .HaveDependencyOn("NetArchTest.SampleLibrary.Data")
    .GetResult()
    .IsSuccessful;

// Classes in the "data" namespace should implement IRepository
result = Types.InCurrentDomain()
    .That().HaveDependencyOn("System.Data")
    .And().ResideInNamespace(("ArchTest"))
    .Should().ResideInNamespace(("NetArchTest.SampleLibrary.Data"))
    .GetResult()
    .IsSuccessful;

"This project allows you create tests that enforce conventions for class design, naming and dependency in .Net code bases. These can be used with any unit test framework and incorporated into a build pipeline. "

Ard

yes, in 2023 I think ArchUnit and its derivatives help address this. At the time I wrote this question this wasnt an option – Birkenhead

Answer 4

You are wanting to solve a people problem with software? Prepare for a world of pain!

The way to solve the problem is to make sure that you have ways of working with people that you don't end up with those kinds of problems.... Pair Programming / Review. Induction of people when they first come onto the project, etc.

Having said that, you can write tools that analyse the software and look for common problems. But people are pretty creative and can find all sorts of bizarre ways of doing things.

Ovarian

Ohh I am feeling the pain alright!!! I was hoping against hope if there were some sort of framework/tool that could analyze/validate some architectural rules I guess there is no shortcut to reviews eh? – Birkenhead

well, by seperating out the assemblies and making the View entirely independent of the model, so the Presenter provides all the objects the view deals with you could verify that the View doesn't use the Model. But thats more pain than its worth. Mostly. – Ovarian

but that would likely just move your problem somewhere else.... introduce more training on how to work within the architectural style you have – Ovarian

Answer 5

Just as soon as everything gets locked down according to your satisfaction, new requirements will arrive and you'll have to break through the side of it.

Enforcing such stringency at the programming level with .NET is almost impossible considering a programmer can access all private members through reflection.

Do yourself and favour and schedule regular code reviews, provide education and implement proper training. And, as you said, it will become quickly evident when you can't write unit tests against it.

Sadfaced