Decisions: Architectural Principles - SingletonTheory/SingletonTheory.github.io GitHub Wiki
Append-Only vs Snapshot Data Strategy
Definitions
Append-Only
Append-Only is a data strategy whereby any updates to the data on an Entity results in an insert into the Data Store.
Snapshot
Snapshot entails that a picture is taken of the data before each data modification.
Summary
With either approach certain design considerations should be taken into account in the Domain code. This means that it increases initial complexity of development. On the pro side of things, using either strategy gives you a full history of the data and how it changed and evolved over time. This could then be used to build workflow applications easier, while giving the Domain access to full audits, undo functionality and more. Another benefit of this implementation is that the majority of databases are optimised for reads & inserts and not for reads & updates. In the second scenario reads are blocked until an update completes or vice versa, while in the first scenario a read can happen while an insert is happening seeing that no lock is required for the data being inserted, it simply appends it to the end of the file.
Framework Considerations
ServiceStack - Default IoC Container
ServiceStack has a default IoC Container that uses Funq. It also allows for your own IoC Containers, which is outlined here.
Additional Reading
- Martin Fowler: http://martinfowler.com/articles/injection.html
- ServiceStack: https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-container
Inversion of Control
Description
Inversion of Control (IoC) Containers enables the Dependency Injection Pattern pattern by creating a container to manage any external dependencies. By applying this pattern it allows for dependencies such as databases, drivers etc. to be injected, which enables testability and encourages good separation of concerns.
Framework Considerations
ServiceStack - Default IoC Container
ServiceStack has a default IoC Container that uses Funq. It also allows for your own IoC Containers, which is outlined here.
Additional Reading
- Martin Fowler: http://martinfowler.com/articles/injection.html
- ServiceStack: https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-container
Repository Pattern
Description
The repository mediates between the data source layer and the business layers of the application. It queries the data source for the data, maps the data from the data source to a business entity, and persists changes in the business entity to the data source. A repository separates the business logic from the interactions with the underlying data source or Web service.
Additional Reading
Multi-Database Support
Description
Singleton Theory supports the database technologies as described below. This allows the users of the Framework and the Application stack to choose their own data store technology and to switch between their databases as they need to without changing any code.
Framework Considerations
ServiceStack - OrmLite
One for the Orm frameworks considered at this stage is ServiceStack's OrmLite framework. https://github.com/ServiceStack/ServiceStack.OrmLite
SingletonTheory OrmLite Providers
By wrapping OrmLite's providers we were able to add support for MongoDB as well. It also gave us an advantage whereby we don't have to write as much code seeing that annotation can be used as defined in the tests which can be found here.
Current Database Support
SQL Server, MySQL and MongoDB.