In my last post we took a look at the CodeOnly feature CTP2 for some demo code.
The sample didn't cover inheritance, so let's make another sample using inheritance. The ADO.NET team's sample covers it, but there are a few things to notice. By default the CodeOnly feature uses TPH (Table Per Hierarchy), which means that all entities in an inheritance tre e(hierarchy) would be stored in a single table.
A simple Hierarchy sample
So let's setup a simple scenario. An abstract class, Person and a derived class Employee.
1: public abstract class Person
2: {
3: public int Id { get; private set; }
4: public string FirstName { get; set; }
5: public string LastName { get;set; }
6: }
1: public class Employee : Person
2: {
3: public string Department { get; set; }
4: }
If we use the ContextBuilder without giving any configuration, this will result in a single table.
To map this hierarchy into two different tables we need to add some configuration to the builder.
First we add a configuration class for Person:
1: public class PersonConfiguration : EntityConfiguration<Person>
2: {
3: public PersonConfiguration()
4: {
5: Property(p => p.Id).IsIdentity();
6:
7: MapHierarchy(p => new
8: {
9: p.Id,
10: p.FirstName,
11: p.LastName
12: });
13: }
14: }
In this configuration class we set Id to be Identity and then we use MapHierarchy to set the column mappings. This will result in in a Table named Persons. We could change the table name in a fluent way using MapHierarchy(…).ToTable(…). Note that the IsIdentity extension also takes a parameter for StoreTableName.
Second we add configuration for the Employee class:
1: public class EmployeeConfiguration : EntityConfiguration<Employee>
2: {
3: public EmployeeConfiguration()
4: {
5: MapHierarchy(
6: e => new
7: {
8: e.Id,
9: e.Department
10: }
11: ).ToTable("Employees");
12: }
13: }
Here we use MapHierarchy again, mapping the Employee properties to a new table. Note that we need to map the identity for the entity here too.
Ok, all done. If we add these configurations to the builder, it will result in the following:
That was simple, note that we didn't configure the string properties, so it defaulted to nvarchar(4000). The CodeOnly feature allows you to configure one table per class in the hierarchy or one table for the inheritance tree. If you would like to mix these options and just split one class in your hierarchy into an table of its own, there seems to be no option (that I can find at least).
Configuration using MEF
Time to spice up this sample a bit: let's build a simple demo ContextBuilderFactory that uses MEF to get all configurations. This is something you also could do with your favorite IOC container. If you're confused about the MEF Container and IOC container, you could read What Is The Difference Between an IoC Container and MEF?. The ContextBuilder is something that you would like to keep and just create new contexts from, so you app doesn’t have to add all configurations each time you create a context.
First we need to change our configuration class to be exportable. We need to add a reference to System.ComponentModel.Composition to our Configuration project. There are several ways of doing the Export. We know that the builder configuration collection is a collection of StructualTypeConfiguration, so that is the type that we want to export. This could be done adding an export attribute on each configuration, or be dependent on an interface or base class for each configuration so we don’t need to attribute every configuration class. For example, you could have a MefEntityConfiguration<TEntity> base class with an InheritedExport attribute. But we're going with the simplest way for this demo. So let's add the following export attribute to our two configuration classes.
Ex
1: [Export(typeof(StructuralTypeConfiguration))]
2: public class EmployeeConfiguration : EntityConfiguration<Employee>
Now we could make a simple factory that uses the MEF container.
1: public class ContextBuilderFactory
2: {
3: public static ContextBuilder<TContext> Create<TContext>() where TContext : ObjectContext
4: {
5: var catalogue = new DirectoryCatalog(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));
6: var container = new CompositionContainer(catalogue);
7: var configs = container.GetExportedValues<StructuralTypeConfiguration>();
8: var contextBuilder = new ContextBuilder<TContext>();
9:
10: foreach(var config in configs)
11: {
12: contextBuilder.Configurations.Add(config);
13: }
14:
15: return contextBuilder;
16: }
17: }
First we create a new DirectoryCatalog, the directory where MEF should look for exports. Then we create a MEF container. With the container we now can get our exports of type StructualTypeConfiguration as an IEnumerable<StructualTypeConfiguration>. After that we create a new ContextBuilder and adds all configurations that we got from the container. Then we return the configured builder.
The factory is now ready to use:
1: [TestMethod]
2: public void SetupWithFactory()
3: {
4: var connectionString = ConfigurationManager.ConnectionStrings["DemoContext"].ConnectionString;
5: var builder = ContextBuilderFactory.Create<DemoContext>();
6:
7: using (var context = builder.Create(new SqlConnection(connectionString)))
8: {
9: if (context.DatabaseExists())
10: {
11: context.DeleteDatabase();
12: }
13: context.CreateDatabase();
14: }
15: }
This way the test project doesn't need a reference to the configuration project, but due to our DirectoryCatalog, the container is going to look for exports in the executing folder of the test. You could copy the Sample.Configuration.dll or add the reference. Note that this is a simple demo and there a few more things that you'd like to do in a real scenario, but that's not in the scope of this post. Please check this post for a more complete example of using CodeOnly and an IOC container.
Download sample
Note that you need to copy the Sample.Configuration.dll as stated above for the test to work. If you don't do this, no configurations are loaded and you end up with a single table.