What do the Patterns do?
IDENTITY FIELD
Saves a database ID field in an object to maintain identity between an in-memory object and a database row.
It's important to use a known identity field as it allows the library to implement a variety of foreign key type work automatically.
IDENTITY MAP
Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.
Without this ability you run the risk of loading a second copy of the object into memory that you have elsewhere. If either of these copies of the object make changes they won't be reflected by the other object and this often leads to terrible bugs that are really hard to find.
LAZY LOADING
An object that doesn't contain all of the data you need but knows how to get it when you need it.
This is used when implementing relationships between objects and delaying the loading of the related objects until you need them.
FACTORY METHOD
Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.
Here, we use the factory method when we load raw data from the database, or to implement interfaces to other data sources. We want to separate where we load/save data from/to with the part that actually uses it. The factory is used to transform raw data into the format the object uses.
BRIDGE
The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently"
We use a Bridge in the generator. We use it to provide an alternate representation of the model, that we then use the alternate model to generate code from. The default SIM tool has it's own format to represent it's model. If we generated directly from SIM's format, then all other bridges to all other tools would have to understand and re-implement SIM's format to be compatible to be generated from. Instead, our format is very much simplified, and we use a bridge to transform SIM's model to a GeneratorSpec model. Any other bridge builder would do the same.
UNIT OF WORK
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
Allows you to save all the dirty objects to the database as a single transaction that rolls back if any of them fail for some reason. Without it you save individual object classes as you need to. The order the dirty flags are set is the order instances are written to the database.
The unit of work also enables blistering fast database writes. While you can save individual objects, using Object.Save(), once you get above 10 saves, it's better to use a unit of work. In our tests, a unit of work saved 9000 inserts into a new database in one second. It does this by writing the changes in memory, then writing the final state of the database as one big file I/O.
SINGLE TABLE INHERITANCE
Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes.
Provides a method for saving multiple sub-classes into a single table.
Saves a database ID field in an object to maintain identity between an in-memory object and a database row.
It's important to use a known identity field as it allows the library to implement a variety of foreign key type work automatically.
IDENTITY MAP
Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.
Without this ability you run the risk of loading a second copy of the object into memory that you have elsewhere. If either of these copies of the object make changes they won't be reflected by the other object and this often leads to terrible bugs that are really hard to find.
LAZY LOADING
An object that doesn't contain all of the data you need but knows how to get it when you need it.
This is used when implementing relationships between objects and delaying the loading of the related objects until you need them.
FACTORY METHOD
Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.
Here, we use the factory method when we load raw data from the database, or to implement interfaces to other data sources. We want to separate where we load/save data from/to with the part that actually uses it. The factory is used to transform raw data into the format the object uses.
BRIDGE
The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently"
We use a Bridge in the generator. We use it to provide an alternate representation of the model, that we then use the alternate model to generate code from. The default SIM tool has it's own format to represent it's model. If we generated directly from SIM's format, then all other bridges to all other tools would have to understand and re-implement SIM's format to be compatible to be generated from. Instead, our format is very much simplified, and we use a bridge to transform SIM's model to a GeneratorSpec model. Any other bridge builder would do the same.
UNIT OF WORK
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
Allows you to save all the dirty objects to the database as a single transaction that rolls back if any of them fail for some reason. Without it you save individual object classes as you need to. The order the dirty flags are set is the order instances are written to the database.
The unit of work also enables blistering fast database writes. While you can save individual objects, using Object.Save(), once you get above 10 saves, it's better to use a unit of work. In our tests, a unit of work saved 9000 inserts into a new database in one second. It does this by writing the changes in memory, then writing the final state of the database as one big file I/O.
SINGLE TABLE INHERITANCE
Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes.
Provides a method for saving multiple sub-classes into a single table.