structuring-avalonia-projects

Guides AvaloniaUI solution and project structure design using naming conventions and layer separation.

Updated Nov 22, 2023
One-click install
npx skills add https://github.com/parksanghoon-sys/TestCode --skill structuring-avalonia-projects-parksanghoon-sys
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: structuring-avalonia-projects
Source: https://github.com/parksanghoon-sys/TestCode/tree/main/src/Modbus/.agents/skills/structuring-avalonia-projects
Command: npx skills add https://github.com/parksanghoon-sys/TestCode --skill structuring-avalonia-projects-parksanghoon-sys

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designing a clean, maintainable AvaloniaUI solution structure is challenging when teams lack consistent naming conventions and clear layer separation, leading to tangled dependencies and untestable code. ## Core Features & Use Cases - Standardized Project Naming: Defines suffix-based conventions such as .Abstractions, .Core, .ViewModels, .AvaloniaServices, .AvaloniaLib, .AvaloniaApp, and .UI for consistent solution organization. - Layer Separation Guidance: Establishes a dependency hierarchy where the Abstractions layer sits at the top, enabling dependency inversion and UI-framework-independent business logic. - Testability Support: Promotes Mock-based testing by routing all dependencies through interfaces injected via a DI container. - Use Case: When starting a new AvaloniaUI desktop application, use this Skill to scaffold the solution with properly named class library, test, ViewModel, and application projects following the recommended dependency hierarchy. ## Quick Start Ask the AI to create a new AvaloniaUI solution structure for a project named MyApp following the standard naming conventions and layer separation guidelines.

Frequently Asked Questions about structuring-avalonia-projects

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure an AvaloniaUI solution with multiple projects?▼

Structure an AvaloniaUI solution using suffix-based project names: .Abstractions for interfaces, .Core for business logic, .ViewModels for MVVM ViewModels, .AvaloniaServices and .AvaloniaLib for Avalonia-specific code, and .AvaloniaApp as the entry point. The Abstractions layer sits at the top of the dependency hierarchy.

What naming conventions should Avalonia projects follow?▼

Avalonia projects should use suffixes indicating their role: .Abstractions for abstract types, .Core for pure C# logic, .Core.Tests for xUnit tests, .ViewModels for MVVM, .AvaloniaServices for dialog and navigation services, .AvaloniaLib for reusable controls, .AvaloniaApp for the entry point, and .UI for custom control libraries.

Why use an Abstractions layer in Avalonia applications?▼

The Abstractions layer houses all interfaces and abstract classes, enabling dependency inversion so concrete implementations are injected via a DI container at runtime. This allows replacing real implementations with Mock objects during testing and keeps higher layers decoupled from concrete types.

Can Avalonia ViewModels be tested independently of the UI framework?▼

Yes, placing ViewModels in a dedicated .ViewModels .NET class library keeps them UI-framework-independent. Combined with interfaces from the Abstractions layer, ViewModels can be unit tested with Mock objects without loading Avalonia runtime components.

What is the difference between AvaloniaLib and UI projects?▼

The .AvaloniaLib project holds reusable UserControls, Windows, Converters, Behaviors, and AttachedProperties, while the .UI project is an Avalonia Custom Control Library containing ControlTheme-based custom controls. They separate general reusable components from themed custom controls.