Stardust documentation

Introduction

logo_smal.png

The Stardust project’s main goal is to provide tools to build fast, scalable and distributed systems with ease and follow best practices.
Building scalable applications that can serve millions of request each day proposes a new set of challenges. The system needs to be scalable in each layer and contains lots of smaller components that serves very specific roles. In one application built on Stardust we have a state less web UI with webapi, an application service that handles working data and business rules, while search and lookup are handles by a separate service. In addition the application rely on several smaller services that provide loging (realtime usage statistics and logging of requests and execution state), storage and caching. The system is deployed on 3 separate environments all with different domains. Having, in this case, 5 deployments in 3 environments where the components need to know about eachother in some way makes configuration managemet hard. The traditional way of dealing with this is to do config transforms in the build process, this however makes it hard to change or add a new service as the clients of the service may not be known to the service developer. Stardust solves this by having a sentralized configuration store that all the komponents know and trust. The framework does the setup and configuration of all endpoints and services as well as the clients.
Underneath the services framework Stardust has a builtin IOC container that handles object activation and life cycle management. [We are currently working on a Service locator type pattern to integrate other IOC into the framework allowing you to use your favorite container].
Some initial performance tests shows that the builtin IOC container performs quite well. Compairing with AutoFac and StructureMap it is just as fast or even faster. However, it is worth noting that AutoFac and StructureMap does allow for interception or AOP. In the scenarios Stardust is designed to operate debugging and troubleshooting is difficult at best and interception makes it harder to step through the code (this is my opinion, you may disagree with me, and that’s why I’m working on a way to connect other IOC’s to the framework).

Philosophy

License

The IOC container

Services framework

Type mapping

Tools

Future changes

Documentation

Sample application

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License