-
Notifications
You must be signed in to change notification settings - Fork 3
Collections
Items are persisted in colections
in the under the Collections folder of the DB directory the client/server is set up to use.
Collections are logical groupings of similar data you want to save. Usually in NoSql DB's these collectios are POCO or DTO objects, that have some convention that you have to follow like a certain ID field and/or Class/Property attributes.
[SomeBsonConvention] // Mixing specific tech with your architecture
public class Rocket
{
// the concept "ID" has nothing to do with the concept of a Rocket
public int ID {get; set;}
public string Name {get; set;}
public double Speed {get; set;}
public bool CanLand {get; set;}
// methods are ignored
void GetDisplayText()
{
return "Rocket " + Name + " can" + CanLand ? "" : " not" + " land."
}
Color color; // non-property members are ignored ?
static int rocketsFired; // static members ignored ?
public Task<double[]> DepleteFuelCells; // non-primitive type, ignored ?
}
Data persistency shouldn't get in the way when doing code-first prototyping, a good architecture allows you to defer major descisions. Saving data should be tool, not a constraint or dependency.
So, you don't have to follow any conventions! You can even save primitive types like "Flash" or 15.11 on their own. You can even save Cats and load them as Ducks.
This flexibility does come at a cost:
// TODO write about implicit conversion & indexing performance
Using a convention based approach, you can avoid having to use the ID when using data entries. The downside is that you might not want all your POCO or DTO objects to implement the IDataEntry interface. If you only develop for an application with a few thousand entries, don't mind removing IDataEntry later or using it anyway, it does simplify database interaction:
// TODO copy paste examples from unit tests
// TODO write this wiki page.. contributions welcome!