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

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

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.