So far, I have found two major points in favor of ArchUnitNet library, compared to NetArchTest. 1. If I have a domain model that implements ITraceableModel, which implements IModel, I can just write it as Classes().That().ImplementInterface(typeof(IModel)). For NetArchTest I whould write domainTypes.That().ImplementInterface(typeof(IModel)).Or().ImplementInterface(typeof(ITraceableModel)). You need to declare all the inheritance, otherwise your classes are not checked properly. 2. When there is an architecture error, ArchUnitNet displays the exact errors, with a description message. It is easy to go to the file and fix it. On the other hand, NetArchTest asserts a true/false statement and does not display any useful information.
1. I'd consider the second approach (NetArchTes) better as it's more explicit. No? 2. Fair, but we could solve it by checking for failing types instead of success flag
@@MilanJovanovicTech #1 when we introduce new types derived from previously checked types, it should "just" work. It's easy to forget to add them to the arch test definitions and all the tests pass. #2 It is a "Result" class. It would've been handly if the FailingTypes collection was not null. It's an extra if statement that could've been avoided. Overall, I've had a better experience with ArchUnitNet.
Really great library :) I would really like to add some checks for Blazor Components, specifically dependencies between different components. Unfortunately the dependencies are only at compile time and not in the compiled code. Do you know of any tool/library to do this?
@@MilanJovanovicTech Lets say we have Child.razor and a Parent.razor and the Parent markup is This rule still passes ArchRuleDefinition .Types() .That() .AreAssignableTo(typeof(Parent)) .Should() .NotDependOnAny(typeof(Child)) .Check(architecture); Does that make more sense?
More in-depth comparison at project level shows that ArchUnitNet has received more fixes/improvements more recently while NetArchTest still has some issues completely unattended since 3 yrs ago that have been fixed in a fork but the original author refuses to attend. That doesn't give me much security about choosing it thinking in the long term.
Fantastic video, thanks. Interested in how you would apply this in a modular monolith with clean architecture projects for each module. Would you duplicate the arch tests in each module? Or create some kind of centralised arch tests that could be applied to all the modules?
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Worth noting that ArchUnitNET is Apache 2.0 licence, so some restrictions and conditions compared to the completely open MIT licence of NetArchTest
Thanks for mentioning that
So far, I have found two major points in favor of ArchUnitNet library, compared to NetArchTest.
1. If I have a domain model that implements ITraceableModel, which implements IModel, I can just write it as Classes().That().ImplementInterface(typeof(IModel)). For NetArchTest I whould write domainTypes.That().ImplementInterface(typeof(IModel)).Or().ImplementInterface(typeof(ITraceableModel)). You need to declare all the inheritance, otherwise your classes are not checked properly.
2. When there is an architecture error, ArchUnitNet displays the exact errors, with a description message. It is easy to go to the file and fix it. On the other hand, NetArchTest asserts a true/false statement and does not display any useful information.
1. I'd consider the second approach (NetArchTes) better as it's more explicit. No?
2. Fair, but we could solve it by checking for failing types instead of success flag
@@MilanJovanovicTech
#1 when we introduce new types derived from previously checked types, it should "just" work. It's easy to forget to add them to the arch test definitions and all the tests pass.
#2 It is a "Result" class. It would've been handly if the FailingTypes collection was not null. It's an extra if statement that could've been avoided.
Overall, I've had a better experience with ArchUnitNet.
Really great library :)
I would really like to add some checks for Blazor Components, specifically dependencies between different components.
Unfortunately the dependencies are only at compile time and not in the compiled code.
Do you know of any tool/library to do this?
"the dependencies are only at compile time and not in the compiled code" - could you explain this part? I'm a bit confused.
@@MilanJovanovicTech Lets say we have Child.razor and a Parent.razor and the Parent markup is
This rule still passes
ArchRuleDefinition
.Types()
.That()
.AreAssignableTo(typeof(Parent))
.Should()
.NotDependOnAny(typeof(Child))
.Check(architecture);
Does that make more sense?
More in-depth comparison at project level shows that ArchUnitNet has received more fixes/improvements more recently while NetArchTest still has some issues completely unattended since 3 yrs ago that have been fixed in a fork but the original author refuses to attend.
That doesn't give me much security about choosing it thinking in the long term.
The author of NetArchTest simply think it's feature complete, so there is no need to make updates.
@@MilanJovanovicTech yup, exactly. Weird take when he still has some issues open from so long ago.
Fantastic video, thanks. Interested in how you would apply this in a modular monolith with clean architecture projects for each module. Would you duplicate the arch tests in each module? Or create some kind of centralised arch tests that could be applied to all the modules?
I just copy the Arch. tests for each module, much easier to maintain if I to customize the rules a bit.
Thx for the warning
Sure thing :)
Whats your vscode theme name, please?
It's ReSharper syntax highlighting
Great!! 😊
Thanks! 😊
Say lie berry one more time
Library
Please do not use the transcript when showing the IDE. If that has crossed your mind
What do you mean by that?
@petropzqi sounds like you've got captions enabled, you can turn them off in your TH-cam app