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