Architecture overview
Ultimately behind-the-scenes ServiceStack is just built on top of Raw ASP.NET IHttpHandler's. Existing abstractions and xmlconfig-encumbered legacy ASP.NET providers have been abandoned, in favour of fresh, simple and clean Caching, Session and Authentication providers all based on clean POCOs, supporting multiple back-ends and all working seamlessly with each other. Our best-practices architecture is purposely kept simple, introduces no new concepts or artificial constructs and can all be eloquently captured in the diagram below:
ServiceStack's Message-based design allows us to easily support typed, generic and re-usable Service Clients for all our popular formats:
Having all clients share the same interface allow them to be hot-swappable at run-time without code changes and keep them highly testable where the same unit test can also serve as an XML, JSON, JSV, SOAP Integration Test.
By promoting clean (endpoint-ignorant and dependency-free) Service and DTO classes, your web services are instantly re-usable and can be hosted in non-http contexts as well. E.g. The client architecture when one of the built-in MQ Host is enabled:
The entry point for all ASP.NET and HttpListener requests is in the ServiceStack.HttpHandlerFactory whose purpose is to return the appropriate IHttpHandler for the incoming request.
There are 2 distinct modes in any ServiceStack application:
- AppHost Setup and Configuration - Only done once for all services. Run only once on App StartUp.
- Runtime - Run on every request: uses dependencies, plugins, etc. defined in the AppHost. Each new request re-binds all IOC dependencies to a new service instance which gets disposed at the end of each request.
The implementation of this can be visualized below:
After the IHttpHandler is returned, it gets executed with the current ASP.NET or HttpListener request wrapped in a common IRequest instance.
The implementation of RestHandler shows what happens during a typical ServiceStack request:
