structuring-avalonia-projects

To structure an AvaloniaUI project for scalable MVVM architecture, separate your solution into Abstractions, Core, ViewModels, and UI layers with strict dependency flow. This enforces separation of concerns, simplifies onboarding, and ensures maintainable code.

The recommended folder layout for a dotnet Avalonia solution organizes projects into Abstractions, Core, AvaloniaServices, AvaloniaLib, AvaloniaApp, and UI. This naming convention improves readability and enforces a clean dependency direction across layers.

Yes, you can apply these project conventions to refactor an existing Avalonia app. The guidelines apply to both creating new AvaloniaUI solutions and refactoring existing projects, ensuring consistent naming and a layered architecture.

The Avalonia project structure needs an Abstractions layer to enable dependency inversion. This allows the UI layer to depend on Core rather than concrete implementations, facilitating easy mocking for testing and enforcing a clean architecture.

The best way to enforce dependency direction in an AvaloniaUI MVVM project is to apply a layered architecture where the UI layer depends on Core, which depends on Abstractions. This explicit project convention prevents circular dependencies and maintains scalability.