6.2 AvaloniaUI Solution and Project Structure
6.2.1 Project Naming Conventions
code
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:
code
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