servicestack-project-structure

name	servicestack-project-structure
description	Understands ServiceStack’s AppHost, service registration, modular layout, and plugin-based architecture.

ServiceStack Project Structure

Follow these conventions when working with or refactoring ServiceStack project layouts.

Standard Layout (Physical Project Structure)

ServiceStack recommends a 4-project structure to ensure a clean separation of concerns:

1. ServiceModel (DTOs):
   • Contains all Request and Response DTOs.
   • Crucial: Must be a dependency-free, logic-free project (POCOs only).
   • This project is shared with clients.
2. ServiceInterface (Implementation):
   • Houses the service implementation classes.
   • References ServiceModel and other logic/dependency projects.
3. AppHost (Web/Host):
   • The entry point (e.g., ASP.NET Core Startup/Program).
   • Configures AppHost, plugins, and dependencies in the IoC container.
   • References ServiceInterface.
4. Tests (Testing):
   • Contains Unit and Integration tests.
   • References ServiceInterface and AppHost.

AppHost & Configuration

• Initialization: ServiceStack is initialized in the AppHost class, which inherits from AppHostBase (for Framework) or AppHost (for .NET Core/6+).
• Configure Method: Use the Configure(Container container) method to register dependencies and plugins.
• Plugins: Use Plugins.Add(new OpenApiFeature()) or similar for modular functionality.

Service Registration

• Services are automatically discovered in assemblies passed to the AppHost constructor.
• Registration is convention-based: any class implementing IService or inheriting from Service in those assemblies will be registered.

Best Practices

• Keep AppHost Lean: AppHost should only focus on configuration and "wiring up" the application.
• Avoid Circular Dependencies: Ensure a strict hierarchy: AppHost -> ServiceInterface -> ServiceModel.
• Modular Layout: For large projects, split the ServiceInterface into multiple projects based on functional areas.