Domain modeling

There are many different approaches to domain modeling with #liveDB. We try not to get in your way and give you as much freedom as possible. However there are a few constraints you must follow:

• You must define a root model class
• The model must derive from LiveDomain.Core.Model
• The model must be marked with Serializable
• Any types referenced from the model must also be marked with Serializable

You can define any fields, properties, events and methods on the model. Collections of custom entities is a common scenario but the sky's the limit!

There are a few different styles of OO

• Transaction script style - The model is mainly a data container exposing its data fields, usually collections. The domain logic is represented by commands and queries which manipulate the model.
• Rich domain model - The model is a facade for your domain exposing behavior in the form of methods while encapsulating data. Commands and Querys are usually thin using this style, containing mostly parameters to be passed to methods on the model. This style plays well with Transparent Proxy.

Unit Testing

Unit testing a Rich domain model is fairly simple. Just arrange, act and assert on a single instance. No need for an engine or commands which is the case with Transaction-script style.

Choosing collection classes

When modeling you have to choose data structures with care. Analyzing data access patterns and frequencies will help you choose between dictionaries, lists, hashsets, queues, stacks, arrays etc

Traditional disk-based relational databases use a structure known as B-tree for both tables and indexes. B-trees provide a reasonable and balanced performance for all types of operations: seek, scan, insert, delete, etc. SortedSet<T> and SortedDictionary<K,V> are pretty good substitutes.