Physical project structure
This page has moved to docs.servicestack.net
Ideally the root-level AppHost project should be kept lightweight and implementation-free. Although for small projects with only a few services it's ok for everything to be in a single project and to simply grow your architecture when and as needed.
For medium-to-large projects we recommend the physical structure below which we'll model using this concrete Events example to describe how we'd typically layout a ServiceStack project. For the purposes of this illustration we'll assume our Application is called EventMan.
The order of the projects also show its dependencies, e.g. the top-level EventMan
project references all sub projects whilst the last EventMan.ServiceModel
project references none:
/EventMan
AppHost.cs //The ServiceStack ASP.NET Web or Console Host Project
/EventMan.ServiceInterface //All Service implementations (akin to MVC Controllers)
EventsService.cs
EventsReviewsService.cs
/EventMan.Logic //For larger projs: pure C# logic deps, data models, etc
IGoogleCalendarGateway //E.g of a external dependency this project could use
/EventMan.ServiceModel //Service Request/Response DTOs and DTO types in /Types
Events.cs //Events, CreateEvent, GetEvent, UpdateEvent DTOs
EventReviews.cs //EventReviews, GetEventReview, CreateEventReview DTOs
/Types
Event.cs //Event type
EventReview.cs //EventReview type
With the EventMan.ServiceModel
DTO's kept in their own separate implementation and dependency-free dll, you're freely able to share this dll in any .NET client project as-is - which you can use with any of the generic C# Service Clients to provide an end-to-end typed API without any code-gen.
The EmailContacts solution details the recommended setup and physical layout structure of typical medium-sized ServiceStack projects. It includes the complete documentation going through how to create the solution from scratch, and explains all the ServiceStack hidden features it makes use of along the way.
- Why ServiceStack?
- Important role of DTOs
- What is a message based web service?
- Advantages of message based web services
- Why remote services should use separate DTOs
-
Getting Started
-
Designing APIs
-
Reference
-
Clients
-
Formats
-
View Engines 4. Razor & Markdown Razor
-
Hosts
-
Security
-
Advanced
- Configuration options
- Access HTTP specific features in services
- Logging
- Serialization/deserialization
- Request/response filters
- Filter attributes
- Concurrency Model
- Built-in profiling
- Form Hijacking Prevention
- Auto-Mapping
- HTTP Utils
- Dump Utils
- Virtual File System
- Config API
- Physical Project Structure
- Modularizing Services
- MVC Integration
- ServiceStack Integration
- Embedded Native Desktop Apps
- Auto Batched Requests
- Versioning
- Multitenancy
-
Caching
-
HTTP Caching 1. CacheResponse Attribute 2. Cache Aware Clients
-
Auto Query
-
AutoQuery Data 1. AutoQuery Memory 2. AutoQuery Service 3. AutoQuery DynamoDB
-
Server Events
-
Service Gateway
-
Encrypted Messaging
-
Plugins
-
Tests
-
ServiceStackVS
-
Other Languages
-
Amazon Web Services
-
Deployment
-
Install 3rd Party Products
-
Use Cases
-
Performance
-
Other Products
-
Future