Srikanth Mandadi of the ADO.NET Entity Framework Team has begun a series on dealing with big EDMs in Entity Framework v1 on the ADO.NET Team blog. Working With Large Models In Entity Framework – Part 1
This is an important problem that needs some good guidance for solving and I'm very happy to see this series.
I talked with one guy in my workshop at DevConnections earlier this month who has to deal with a model that is for a hospital database and would have hundreds and hundred of entities that he can't envision how to break up into smaller models where there are no relationships going across.
One of the options for doing this is with the Using element which allows you to break a model up into multiple CSDL's and still benefit from associations across the two models. It's not a Designer friendly solution and the MSDN docs don't really have much detail on it so I thought I would try to implement it.
When I tried it out a few days ago, I wrote the following which I realize I never posted. And now Srikanth has written about this scenario in more detail in today's post: Working With Large Models In Entity Framework – Part 2. But I still thought I would share my thoughts as well. The bottom line is that as powerful as the Using construct is, it's a pain in the butt to implement.
Starting with AdventureWorksLT, I wanted to strip out the entities for the Product details (ProductModel, ProductDescription, etc)
I tried creating a second schema right in the EDMX file and adding the Using element to the main schema.
<edmx:ConceptualModels>
<Schema Namespace="AdventureWorksSuperLTModel" Alias="Self" xmlns="http://schemas.microsoft.com/ado/2006/04/edm">
<!--Using element pointing to new schema -->
<Using Namespace="AWProductDetailModel" Alias="BaseModel"/>
...entities & associations for main csdl...
</Schema>
<!--NEW Schema-->
<Schema Namespace="AWProductDetailModel" Alias="Self">
<EntityType Name="ProductModel">
<Key>
<PropertyRef Name="ProductModelID" />
</Key>
<Property Name="ProductModelID" Type="Int32" Nullable="false" />
<Property Name="Name" Type="String" Nullable="false" MaxLength="50" Unicode="true" FixedLength="false" />
<Property Name="CatalogDescription" Type="String" MaxLength="Max" Unicode="true" FixedLength="false" />
<Property Name="rowguid" Type="Guid" Nullable="false" />
<Property Name="ModifiedDate" Type="DateTime" Nullable="false" />
<NavigationProperty Name="Product" Relationship="AdventureWorksSuperLTModel.FK_Product_ProductModel_ProductModelID" FromRole="ProductModel" ToRole="Product" />
<NavigationProperty Name="ProductModelProductDescription" Relationship="AdventureWorksSuperLTModel.FK_ProductModelProductDescription_ProductModel_ProductModelID" FromRole="ProductModel" ToRole="ProductModelProductDescription" />
</EntityType>
</Schema>
</edmx:ConceptualModels>
That is unfortunately not how to do it. This is attempting to solve the problem in the EDMX file which is the designer file but the solution is not supported in the designer. You need to do this in raw CSDL files, not the EDMX.
Also, since Using isn't supported by the designer, you wouldn't be able to open the EDMX file in the designer anyway. Additionally you can't use the code gen tool from the designer.
So the way to do this is either start with your entire model in the designer and set the Metadata Artifact property so that it spits out the three files (CSDL, MSL, SSDL) rather than embedding them into the assembly. Then create the separate CSDL, moving the entities that you want separated into there. In the primary CSDL you need not only the Using element, but you'll need to property reference the new Model's name in any reference to the entities that live there (eg in Associations). Then you need to use the manual EDMGEN command line tool to generate your classes.
It's not for the feint of heart or those who, like me, are short on time.
Srikanth included sample xml files in his post so you can see how the puzzle fits together, but I'm curious how the classes surface. I am guessing you still use everything in a single context. Therefore the benefit is less cumbersome models, but since I can't use them in the designer, today that's more cumbersome for me.
I'll be keeping an eye for the rest of the posts in this series which suggest solutions that are supported by the designer.
