| name | structuring-avalonia-projects |
| description | Guides the design of AvaloniaUI solution and project structures. Use when creating new AvaloniaUI solutions or organizing projects following naming conventions and layer separation. |
6.2 AvaloniaUI Solution and Project Structure
6.2.1 Project Naming Conventions
SolutionName/
├── SolutionName.Abstractions // .NET Class Library (Interface, abstract class, and other abstract types)
├── SolutionName.Core // .NET Class Library (Business logic, pure C#)
├── SolutionName.Core.Tests // xUnit Test Project
├── SolutionName.ViewModels // .NET Class Library (MVVM ViewModel)
├── SolutionName.AvaloniaServices // Avalonia Class Library (Avalonia-related services)
├── SolutionName.AvaloniaLib // Avalonia Class Library (Reusable components)
├── SolutionName.AvaloniaApp // Avalonia Application Project (Entry point)
├── SolutionName.UI // Avalonia Custom Control Library (Custom controls)
└── [Solution Folders]
├── SolutionName/ // Main project group
└── Common/ // Common project group
Naming by Project Type:
.Abstractions: .NET Class Library - Defines abstract types like Interface, abstract class (Inversion of Control).Core: .NET Class Library - Business logic, data models, services (UI framework independent).Core.Tests: xUnit/NUnit/MSTest Test Project.ViewModels: .NET Class Library - MVVM ViewModel (UI framework independent).AvaloniaServices: Avalonia Class Library - Avalonia-related services (DialogService, NavigationService, etc.).AvaloniaLib: Avalonia Class Library - Reusable UserControl, Window, Converter, Behavior, AttachedProperty.AvaloniaApp: Avalonia Application Project - Entry point, App.axaml.UI: Avalonia Custom Control Library - ControlTheme-based custom controls
Project Dependency Hierarchy:
SolutionName.AvaloniaApp
↓ references
SolutionName.Abstractions (Top layer - does not depend on other projects)
↓ references
SolutionName.Core
Role of the Abstractions Layer:
- Houses all Interfaces and abstract classes
- Dependency inversion through abstract types instead of direct references to concrete types (Dependency Inversion Principle)
- Actual implementations injected via DI container at runtime
- Can be replaced with Mock objects during testing
