Updated readme

Also added some more helpers for DI

Author: grofit

docs/architecture/entity-collections.md

@@ -18,4 +18,4 @@ So taking the above example again, if you were to partition your collections so
 
 ## Where do they live?
 
-So there is an `EntityCollectionManager` which acts as the container for all the entity collections 
+So there is an `EntityDatabase` which acts as the container for all the entity collections 

docs/breaking-changes.md

@@ -1,5 +1,9 @@
 # Breaking Changes
 
+## 3.9.0 -> 3.10.0
+
+- IEntityCollectionManager no longer contains EntityCollections its now within `IEntityDatabase`, which is within there
+
 ## 3.8.0 -> 3.9.0
 
  - `IObservableScheduler` is now known as `IUpdateScheduler` and uses an `ElapsedTime` object not `TimeSpan`

docs/framework/blueprints.md

@@ -6,7 +6,7 @@ how they wish to implement blueprints, as you can add as much configurable prope
 
 Here is an example of a blueprint:
 
-```
+```csharp
 public class PlayerBlueprint : IBlueprint
 {
 	public string Name {get;set;}
@@ -27,7 +27,7 @@ public class PlayerBlueprint : IBlueprint
 Pools are aware of blueprints and you can create an entity with a blueprint to save you the time of having to create the entity 
 then manually applying all the components, which would look like:
 
-```
+```csharp
 var hanSoloEntity = somePool.createEntity(new PlayerBlueprint{ 
 	Name = "Han Solo", 
 	Class = "Smuggler", 
@@ -40,7 +40,7 @@ You have 2 options of applying blueprints to entities, one would be to just new
 `Apply` method passing in the entity, or you could use the available extension methods to apply directly from the entity, 
 this is also chainable so you are able to apply multiple blueprints to the same entity if you wanted, like so:
 
-```
+```csharp
 entity.ApplyBlueprint(new DefaultActorBlueprint())
 	.ApplyBlueprint(new DefaultEquipmentBlueprint())
 	.ApplyBlueprint(new SetupNetworkingBlueprint());

docs/framework/entities.md

@@ -12,11 +12,17 @@ As mentioned entities are created within collections and you can have many entit
 
 ### From `IEntityCollectionManager`
 
-- `myCollectionManager.CreateObservableGroup(myGroup, optionalPoolName)`
+- `myCollectionManager.GetObservableGroup(myGroup, idsForCollectionsToCheck)`
 
 This is probably the most common approach, you get your `IEntityCollectionManager` instance (usually injected in to your class) and you call `CreateObservableGroup`, this will create or return an existing observable group for you which internally contains the `Entities` that match the group for you to query on further. This is often a better approach than accessing entities directly. (read more on this in querying/filtration docs)
 
-- `myCollectionManager.GetEntitiesFor(myGroup, optionalPoolName)`
+- `myCollectionManager.EntityDatabase.*`
+
+The entity collection manager exposes the entity database which can be queried for more info 
+
+### From `IEntityDatabase`
+
+- `entityDatabase.GetEntitiesFor(myGroup, idsForCollectionsToCheck)`
 
 This is not used often but is there for convenience, it allows you to just get back an `IEnumerable<IEntity>` collection which contains all entities which match the group, so it you can query on the matching entities further however you want.
 

docs/framework/groups.md

@@ -18,13 +18,13 @@ There are a few different ways to create a group, here are some of the common wa
 
 There is a `Group` class which implements `IGroup`, this can be instantiated and passed any of the components you want to target, like so:
 
-```c#
+```csharp
 var group = new Group(typeof(SomeComponent));
 ```
 
 There are also some helper methods here so you can add component types if needed via extension methods, like so:
 
-```c#
+```csharp
 var group = new Group()
     .WithComponent<SomeComponent>()
     .WithoutComponent<SomeOtherComponent();
@@ -36,7 +36,7 @@ This is a halfway house between the builder approach and the instantiation appro
 
 So there is also a `GroupBuilder` class which can simplify making complex groups, it is easy to use and allows you to express complex group setups in a fluent manner, like so:
 
-```c#
+```csharp
 var group = new GroupBuilder()
     .WithComponent<SomeComponent>()
     .WithComponent<SomeOtherComponent>()
@@ -49,7 +49,7 @@ So if you are going to be using the same groupings a lot, it would probably make
 
 It is quite simple to make your own group, you just need to implement the 2 getters:
 
-```c#
+```csharp
 public class MyGroup : IGroup
 {
     public IEnumerable<Type> RequiredComponents {get;} =  return new[] { typeof(SomeComponent), typeof(SomeOtherComponent) };

docs/framework/observable-groups.md

@@ -5,7 +5,7 @@ So now you know what entities are and how you can get hold of them, its worth go
 ## Filtration Flow
 
 ```
-IEntityCollectionManager	<-  This contains all collections, which in turn contains ALL entities
+IEntityCollectionManager	<-  This contains the database which contains all collections, which in turn contains ALL entities
      |
      |
 IObservableGroup      		<-  This filters all entities down to only ones which are within the group
@@ -15,7 +15,7 @@ IComputedGroup        		<-  This acts as another layer of filtration on an IObse
                           		i.e Top 5 entities with PlayerComponent sorted by Score
 ```
 
-## IEntityCollectionManager
+## IEntityCollectionManager || IEntityDatabase
 
 The entity collection manager is the root most point where all entity queries should originate from.
 

docs/framework/systems.md

@@ -16,7 +16,7 @@ This is a niche system for when you want to carry out some logic outside the sco
 more fine grained control over how you deal with the entities matched.
 
 Rather than the `SystemExecutor` doing most of the work for you and managing the subscriptions and entity interactions 
-this just provides you the `GroupAccessor` for the entities targetted and its up to you to control how they are 
+this just provides you the `GroupAccessor` for the entities targeted and its up to you to control how they are 
 dealt with.
 
 The `StartSystem` method will be triggered when the system has been added to the executor, and the `StopSystem` 
@@ -30,4 +30,4 @@ So by default (with the default implementation of `ISystemExecutor`) systems wil
 2. Implementations of `IReactToEntitySystem`
 3. Other Systems
 
-However within those groupings it will load the systems in whatever order Zenject (assuming you are using it) provides them, however there is a way to enforce some level of priority by applying the `[Priority(1)]` attribute, this allows you to specify the priority of how systems should be loaded. The ordering will be from lowest to highest so if you have a priority of 1 it will load before a system with a priority of 10.
+However within those groupings it will load the systems in whatever order Zenject/Extenject (assuming you are using it) provides them, however there is a way to enforce some level of priority by applying the `[Priority(1)]` attribute, this allows you to specify the priority of how systems should be loaded. The ordering will be from lowest to highest so if you have a priority of 1 it will load before a system with a priority of 10.

docs/infrastructure/dependency-injection-abstraction.md

@@ -33,7 +33,7 @@ If you want to configure how a binding should work, you can pass into the `Bind`
 ### AsSingleton: `bool`
 
 Setting this to `true` will mean that only one instance of this binding should exist, so if you were to do:
- ```c#
+```csharp
 Bind<IEventSystem, EventSystem>(new BindingConfiguration{AsSingleton = true});
 ```
 Then resolve `IEventSystem` in multiple places you will always get back the same instance, which is extremely handy for infrastructure style objects which should act as singletons. If you provide `false` as the value it will return a new instance for every resolve request.
@@ -46,7 +46,7 @@ This will allow you to give the binding a name for resolving via name.
 
 This allows you to bind to an actual instance of an object rather than a type, which is useful if you need to manually setup something yourself.
 
-```c#
+```csharp
 var someInstance = new Something(foo, bar);
 Bind<ISomething>(new BindingConfiguration{ToInstance = someInstance});
 ```
@@ -55,7 +55,7 @@ Bind<ISomething>(new BindingConfiguration{ToInstance = someInstance});
 
 This allows you to lazy bind something to a method rather than an instance/type, which is useful if you want to setup something in a custom way once all DI configuration has been processed.
 
-```c#
+```csharp
 var bindingConfiguration = new BindingConfiguration({
     ToMethod: container =>
       {
@@ -85,7 +85,7 @@ The configuration object is simple but can be unsightly for larger configuration
 
 There is a builder pattern helper which lets you setup your binding config via a builder rather than an instance of `BindingConfiguration`, this can be used by just creating a lambda within the bind method like so:
 
-```c#
+```csharp
 Bind<ISomething>(config => config
   .AsSingleton()
   .WithName("something-1")
@@ -95,7 +95,7 @@ Bind<ISomething>(config => config
 
 This lets you setup the configuration in a nice way, it also has type safety so you can setup instances and methods using it like so:
 
-```c#
+```csharp
 // With instance
 Bind<ISomething>(config => config
   .ToInstance(new InstanceOfISomething())
@@ -120,7 +120,7 @@ Bind<ISomething>(config => config
 
 There is also another helper which allows you to get an `IObservableGroup` directly from the container, this internally gets the instance of the `IEntityCollectionManager` and requests an observable group of a given type like so:
 
-```c#
+```csharp
 // By group
 var observableGroup = container.ResolveObservableGroup(new MyGroup());
 // By required components

docs/introduction/setup.md

@@ -67,15 +67,18 @@ public abstract class EcsRxApplication
 		// For creating entities, collections, observable groups and managing Ids
 		var entityFactory = new DefaultEntityFactory(new IdPool(), componentRepository);
 		var entityCollectionFactory = new DefaultEntityCollectionFactory(entityFactory);
+		var entityDatabase = new EntityDatabase(entityFactory);
 		var observableGroupFactory = new DefaultObservableObservableGroupFactory();
-		EntityCollectionManager = new EntityCollectionManager(entityCollectionFactory, observableGroupFactory, componentLookup);
+		EntityCollectionManager = new EntityCollectionManager(observableGroupFactory, entityDatabase, componentLookup);
 
 		// All system handlers for the system types you want to support
 		var manualSystemHandler = new ManualSystemHandler(EntityCollectionManager);
+		var basicSystemHandler = new BasicSystemHandler(EntityCollectionManager);
 
 		var conventionalSystems = new List<IConventionalSystemHandler>
 		{
-			manualSystemHandler
+			manualSystemHandler,
+            basicSystemHandler
 		};
 
 		// The main executor which manages how systems are given information

docs/performance/component-type-lookups.md

@@ -8,7 +8,7 @@ So if you are happy to provide a type index/id with your call it will bypass the
 
 So this change means **YOU** have to tell EcsRx ahead of time what indexes/ids to use for your components and provide that data to the rest of your codebase, its easiest to do this by making a class with static int properties like so:
 
-```c#
+```csharp
 public static class ComponentLookupTypes
 {
     public static int NameComponentId = 0;
@@ -19,7 +19,7 @@ public static class ComponentLookupTypes
 
 Then you can just reference these types anywhere which satisfies the telling of the entity the index, and you then just need to make sure when the application is created it uses these explicit lookups rather than auto generating them, generally done by making your own module and loading it like so:
 
-```c#
+```csharp
 public class CustomComponentLookupsModule : IDependencyModule
 {
     public void Setup(IDependencyContainer container)