Genome is an object-relational mapping tool designed exclusively for the Microsoft .NET platform.
Developers building .NET enterprise applications that store durable state in a relational database need to overcome the impedance mismatch between the object-oriented business model and the relational data model. Layered architectures address this mismatch in the data access tier, which takes up a significant proportion of development efforts when implemented manually. Apart from the purely entity-relational mapping aspect, it is quite hard to encapsulate data query logic formulated in SQL, degrading this layer’s maintainability and flexibility.
Genome is an object-relational mapping (O/R mapping) tool that automatically persists .NET classes in relational databases. It generates the data access layer from the class model and schema mapping to the relational model provided by the developer.
You no longer need to implement object CRUD (Create, Read, Update, Delete) operations manually. As a unique feature, Genome’s object query language (OQL) and LINQ compatibility allows you to encapsulate and reuse query logic of the business layer in the domain model, without introducing unnecessary roundtrips to the database.
Object-relational mapping with Genome reduces the cost of maintaining object-oriented business models when working with relational database systems for business data storage by
· Allowing query logic to be encapsulated and reused in the domain model. Queries are expressed against the domain model rather than against the physical database model.
· Allowing the data structure of the business model to be modified and refactored with minimal impact on existing query logic.
· Allowing refactoring of the physical database structure with minimal impact on existing query logic.
· Automatically generating object CRUD (Create, Read, Update, Delete) operations from mapping data.
· Compiling and parsing static queries (mapped in the domain model) during build time.
· Generating strongly typed dynamic queries.
· Providing flexible mechanisms for changing data retrieval and data caching behaviour without affecting or changing existing business logic and data query logic code.
· Providing flexible mechanisms for changing transactional behaviour without affecting or changing existing business logic.
Overall, Genome reduces brittleness and improves maintainability of the data access layer, leading to significant reductions in development effort not only during the initial implementation, but also subsequently in the maintenance of the code.
Genome 4.x exclusively supports Microsoft .NET 3.5. Earlier versions of Genome (3.x, 2.x) also support .NET 2.0 and .NET CLR 1.1.
Genome currently supports the following database platforms:
· Microsoft SQL Server 2000, 2005 and 2008
· Microsoft SQL Server CE
· Oracle 9i and 10g
· IBM DB2 on Linux, Unix, Windows and i-Series with the ADO.NET provider of DataDirect (not included with Genome)
Additional database platforms can be supported upon request.
The first version of Genome (1.x) was developed in 2002 for .NET CLR 1.0. Genome version 2.0 was made publicly available in early 2003 and initially supported .NET CLR 1.0 and 1.1. Later, support for .NET CLR 1.0 was deprecated. From the beginning of 2005 onwards, Genome (version 2.2 and later) has supported both .NET CLR 1.1 and 2.0.
Version 3.0 marks a milestone in Genome’s history as it exclusively supports Microsoft .NET CLR 2.0 and its native features, such as:
· Generics, especially for collection handling
· Generic nullable types
· System.Transactions
· MSBuild project integration
Genome 3.x is also already prepared for the Microsoft compiler extensions for C# and VB.NET which provide native query expression capabilities (LINQ – Language Integrated Query).
Genome 3.x can be used with Visual Studio 2005 and Visual Studio 2008 (supporting LINQ).
Version 4.0 of Genome provides exclusive support for Visual Studio 2008, .NET framework 3.5 and LINQ and introduces major new features and tools such as the Genome Messaging Extensions and Genome Database Management Extensions. Genome 4.0 is almost fully backwards compatible with Genome 3.x to provide a seamless upgrade experience.
When building applications with Genome, you implement an object-oriented business layer with any .NET CLR language (e.g. C# or VB.NET). Basically, the business layer consists of classes which specify the following elements:
· Scalar Data (value types)
· References (reference types, pointing to instances of another class)
· Relations (collections of references to instances of one class)
· Behaviour (methods)
In addition to the .NET language source code, you need to specify a mapping of the object model to the relational database system that will store the state:
· Classes are mapped to tables in the database that store instances of the class, whereby class hierarchies can be mapped to one or multiple tables.
· Scalar data of the classes is mapped to fields in the table that stores instances of the class.
· References to instances of another class are mapped to foreign key fields in the table that stores instances of the class.
· Relations are mapped using predefined patterns that specify the foreign key relation of the children (1:n) or the association table (n:m).
· Relations and references to instances of another class can also be mapped with arbitrary queries expressed in OQL, Genome’s Object Query Language, or LINQ. Query expression can be composed out of other LINQ or OQL expressions.
· Behaviour without side effects that can be expressed in SQL (e.g. the method Path.Join()) can be mapped to be called from LINQ or OQL.
The mapping information is captured in a separate Visual Studio project introduced by Genome: the DataDomain Schema project. Mapping information for each class is maintained in one or more XML files. The mapping information is an additional source code artefact requiring version control, just like any other source code.
The XML mapping files can be forward engineered from the class model source code.
In addition, Genome offers the possibility of reverse engineering the class model and the mapping from an existing relational database system.
When building the solution in Visual Studio, the Genome DataDomain Schema Compiler (ddsc.exe) compiles the provided mapping information after the business assembly has been compiled by csc.exe (or another .NET language compiler). The DataDomain Schema project takes care of initiating ddsc.exe in the build process accordingly. Building the data access layer during compile time has several benefits:
· Errors in the mapping, especially in queries mapped with LINQ or OQL, are discovered during compile time and do not lead to hard-to-detect runtime errors.
· Mapping schema processing takes place during compile time, improving performance during runtime.
The result of the DataDomain Schema compilation is a binary .NET assembly, called Schema Assembly. Optionally, ddsc.exe can also create a SQL create script for the database structure mapped in the DataDomain Schema.
As the DataDomain Schema Project file is MSBuild-compatible, Genome’s compilation can also integrate with a custom MSBuild process (such as Microsoft TeamBuild).
After compiling the business layer and DataDomain Schema, the mapped database can already be accessed by a development tool introduced by Genome, the Genome Query Analyzer. It allows you to load a Genome schema assembly to express arbitrary LINQ and OQL queries against the mapped business layer. You can see the resulting SQL query executed against the database. The results of the query are displayed in a property grid that shows the objects resulting from the query.
A client using a Genome-mapped business layer has to reference the business layer assembly and in addition needs to load the desired schema assembly that provides the mapping information to a specific database platform. The client instantiates a Genome DataDomain (a Genome API class) with the loaded schema assembly and a connection string to the desired database. The DataDomain provides access to the database and allows the client to execute queries as well as create new objects in the database.
The client also needs to set up a Genome Context (another Genome API class) which manages state for persistent objects loaded into the AppDomain. The Context is responsible for caching, update tracking, object level locking and transactional behaviour when working with persistent objects.
Genome consists of the following components:
Genome integrates with Visual Studio 2008 and introduces new project types to the Visual Studio development system. Genome’s database reverse engineering wizard and forward engineering features also integrate with Visual Studio.
Note that project integration does not work with Visual Studio Express editions. However, the DataDomain Schema project can be built with a manual MSBuild job.
Visual Studio integration is automatically installed during Genome setup.
The DataDomain Schema Compiler executes during the build process to compile the schema assembly. It is not required during runtime.
The DataDomain Schema Compiler is located in the {Genome installation folder}\bin directory.
The Genome runtime API provides Genome runtime infrastructure such as the DataDomain or the Context. It is used by the Genome-mapped persistent classes and the related business services. Also the clients connected to these business services might use the Genome runtime API.
The Genome runtime API assemblies are located in the {Genome installation folder}\bin directory. The most important Genome API assembly is TechTalk.Genome.dll.
Genome provides a set of extensions that do not directly belong to the Genome core but help integrate Genome with other technologies. The extensions are provided in source code to help implement integration with similar technologies and to allow you to customise according to your requirements.
The Genome extensions are located in the {Genome installation folder}\Extensions directory.
The Genome messaging extensions (GMX) provide a package of framework features and tools that aid the developer in authoring distributed service-oriented applications using Genome on the server-side. GMX supports any communication architecture where data transfer objects (messages) of a service interface are (partially) composed of server-side Genome mapped business entities.
GMX has been introduced with Genome 4.0. Further information can be found in the according User’s Guide chapter.
The Wire Object Protocol (WOP) is a separate feature of Genome that serialises Genome interconnected persistent object graphs into independent hierarchical object graphs for exposure on service boundaries.
The WOP package consists of an own compiler (wopc.exe), a Visual Studio project type, runtime API and documentation. WOP has been introduced in Genome 2.x and is provided for compatibility reasons in future releases. However, no new features are implemented in WOP anymore as it is superseded by Genome Messaging Extensions, mentioned above.
Genome documentation can be found in the {Genome installation folder}\Documentation directory.
Genome samples (in C# and VB.NET) for different architectural scenarios can be found in the {Genome installation folder}\Samples directory.
The Genome license file is automatically distributed with the Evaluation edition of Genome. License files for all other editions are distributed by e-mail and must be provided when installing Genome.
The license file is only required by Genome ddsc.exe, Query Analyzer and wopc.exe. It does not need to be distributed when deploying solutions.
The Genome setup installs Visual Studio integration for Genome and all Genome compilers, APIs, samples and documentation.
For non-evaluation editions, the license file can be provided during setup or copied to the {Genome installation folder}\bin directory manually afterwards.
Because of its Visual Studio integration, it is not possible to install multiple versions of Genome for a specific Visual Studio version. However, newer versions of the Visual Studio integration work with older versions of the Genome ddsc.exe compiler.
When setting up a solution, it is recommended to copy the files from the {Genome installation folder}\bin directory in an external dependencies directory of the solution, which is managed by the source control system of the solution. Projects should reference Genome API assemblies relatively from the solutions’ own external dependency folders. The DataDomain Schema Project should also be configured to execute ddsc.exe from the external dependency folder, configured relatively to the root of the solution (DataDomain Schema Project Properties in Visual Studio solution explorer).
Specifying relative paths for Genome runtime assemblies and DataDomain Schema compiler ensures that your solution can be compiled in different local working folders in different development machines working with the solution.
This solution setup decouples the Genome version currently installed on the developer machine from the Genome version used by the project. As long as the developer machine has an installed version of Genome that provides Visual Studio integration, the project can be retrieved from the source control system and compiled with the project’s Genome version independent of the developer machine’s configuration.
Uninstalling an old Genome version and installing a newer one on a developer machine does not automatically upgrade existing projects to use the newer Genome API and Genome compiler. Projects can then be upgraded explicitly one by one by updating the contents of the {Genome installation folder}\bin directory in the corresponding project’s external dependency folder.
The easiest way to compile a Genome project on the build server is to install it by executing the Genome installation package. Note that Genome licensing allows to install Genome on different physical machines, as long as the user executing DDSC (initiating the build) is licensed to use Genome.
If you don’t want to run the Genome installer package on the build server, you can also do a manual installation:
1) Provide DDSC.EXE and the Genome runtime APIs in a project external folder, as recommended in Developing with multiple Genome versions in parallel. Make sure the DataDomain schema project executes DDSC from this location.
2) Copy the contents of {Program files installation directory}\MSBuild\TechTalk\Genome to the according location on the build server. This enables MSBuild integration for the DataDomain schema project.
When deploying Genome applications, it is sufficient to deploy all assemblies of the client build output directory. Genome does not need to be installed on the target deployment system, as the Visual Studio integration, Schema Compiler, documentation, samples and license file are not required for runtime deployment.
Although not required for compiling, it is recommended to set up a project reference from the client project to the DataDomain schema project. This ensures that the latest compiled schema assembly is included automatically in the build output directory of the client using the Genome mapped business layer.
Different editions of Genome are available. You can find more information about different editions of Genome here.
| Getting started | Mapping persistent objects |