structuring-avalonia-projects

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