When to Use Metalama

Metalama is not for every project. Consider using Metalama if one of the following situations applies to your project:

• Large projects. Your project contains dozens of entities and hundreds of properties or methods requiring the same behaviors.
• Large teams. There is a large team of developers, and it is challenging to align everyone on consistent patterns and practices.
• Long lifecycle. You must maintain the project for several years, so an investment in long-term quality makes sense.

When not to use Metalama

Conversely, avoid using Metalama if:

• Small and simple projects. If your project is trivial, the added complexity might outweigh the benefits. As a rule of thumb, each aspect should be applied at least 20 times to justify its use.
• Unexperienced team. Don’t embark on a Metalama journey if you lack senior developers or architects on your team. Like any sharp tool, Metalama requires maturity and wisdom in selecting use cases; misuse can introduce unnecessary complexity.

Which factors are almost irrelevant

• Code-generation overhead. Metalama expands aspects into plain C# at compile time (there is no run-time engine), so the generated code runs exactly like the same logic written by hand, and sometimes faster: idiomatic hand-written C# favors compact, readable patterns, while a generator can emit an uglier but faster one. The functionality an aspect adds still costs what it would cost either way; Metalama itself adds no run-time overhead.
• Compilation time. Metalama typically adds 25% to your dotnet build time, which is probably not a big difference for most projects. If it does seem important, it might mean Metalama’s benefits won’t outweigh the added complexity.

What are the principal use cases?