So an application I work on currently uses Linq2SQL and maps classes 1-1 to the database schema. This is generally realistic but inconvenient for a certain area of the DB. I am experimenting with EntityFramework 4.1 and seeing if I can get a more natural strongly-typed mapping for this given area.
The area looks like somewhat like this (each table has a Guid-uniqueidentifier for the ID of each row):
tblSubscription [has one Service, has many SubscriptionParameters]
– fkService (Guid)
tblService [has many Subscriptions, has many ServiceParameters]
– sServiceType (String)
tblSubscriptionParameter [has one Subscription, has one ServiceParameter]
– sValue (String – often the string representation of an int or a bool)
– nIndex (Int – for multiple values corresponding to the same service parameter)
– fkServiceParameter (Guid)
tblServiceParameter [has one Service, has many SubscriptionParameters]
– sName (String)
– fkService (Guid)
The fundamental table here is Subscriptions. There are some different specialized types of subscriptions that I would like to hard code. The advantage this would give me is that I might be able to write something resembling:
var allTestParams = ...SecretSubscriptions.Select(s => s.TestParameter)
instead of the rather ugly pattern I must follow using Linq2SQL:
var allTestParams = ...Subscriptions.Where(s => s.Service.Name == "SecretService")
.Select(s => s.SubscriptionParameters.First(sp =>
sp.ServiceParameter.Name == "TestParameter").Value);
So I would like to have specialized subscription classes that inherit from some base subscription class that explicitly type out which Service type they belong to, and have properties that can get and set to specified SubscriptionParameters. At the same time I want to use a generic subscription class with simple access to a collection of Parameters for certain applications (e.g. auditing) which will interact with parameters without really caring about what they represent.
How can I configure EntityFramework so I can code more fluidly with stronger type enforcements?
EF will not help you with this. It can help you with mapping general subscriptions to specialized types via table per hierarchy inheritance (but Linq-to-sql can do it as well) but it will not allow you mapping related entities as parameters of the derived subscription type. It would require custom database views and stored procedures for modifications.