Namespaces and generated classes in Model First.

Topics: EF Designer, EF Runtime, General
May 27, 2013 at 7:17 PM
Any chance to get an update that prefixes the model names with the schema and then generates classes that adhere to that name?

So that [Stg].[Trade] turns into - as namespaces are ignored in entity framework - the StgTrade class?

I have a couple of larger projects that are fighting to be used in Entity Framework because an old pattern is that every subsystem has unique table names within it's subsystem, and the subsystem is a schema. In the above example I have [Trade] in [trd],[sim] and [simstg] (Trading, Simulation and Simulation-Staging) and thus can not use Entity Framework at all. Multiple similar applications here.

Manipulating the code generation is not good enough - that has to come, at least as an option - from the tool support. We use Model FIrst for the obvious reason that there is no proper schema support in Entity Framework - not when you REALLY use SQL Server (partitioning, compression, filtered indices and all that).
Developer
May 27, 2013 at 8:32 PM
I think that from tooling perspective the only way to achieve this would be to write an extension to the designer that would tweak the model the way you need it to be tweaked. I have not tried doing something like this before so I am not sure exactly sure what is possible and what is not but if you need assistance I can investigate and help you with this excersize.
May 31, 2013 at 12:13 PM
It would be nice because there are a significant number of design decisions that make EF Pretty unusable for a larger project imho, and some of that resolves around the name generation. For our scenario it would be best if the designer would be stupid and just take things as they are in the database. The fact that namespaces get ignored all around the place makes it unbearable - just was hit by a "Cleanup1" stored procedure because we now have a stored procedure in 2 schemas with the name "cleanup". Seems modifying the edmx does not help - any resync happily undoes that. Code first? Possible, but we need full SP ability (stored procedures). Considering that as alternative, though.

Personally I start seeing the whole "edmx" thing as a dead end given the number of not too smart design decisions. There is not a single place where the schema seems to be exposed to the UI - try "add function import". NICE dropdown of all functions, no filter (try that with hundreds - fun) and no schema. Obviously none of the designers of that thing ever used it. Given that this is a larger project - and that schema names are used similar to .NET namespaces to isolate subsystems - seems dead.

Do you think those "schema issues" can be fixed in an extension? Can you point me to some sources to get started - all links I find are seriously ourdated (ef4 timeframe).
Developer
Jun 4, 2013 at 6:04 AM
In general the EF Designer exposes only CSpace concepts and therefore the schema as an SSpace concept is not exposed. Also note that even though the designer by default creates a 1:1 mapping between tables and entity types this in general does not have to be true - EF supports different mapping strategies and in some cases an entity in the conceptual model can be mapped to multiple tables in the database. When writing an extension however you should be passed the whole model as an edmx XDocument and therefore you should be able to access SSpace constructs - including schema name. With that information you can then update the conceptual model and the mapping (if necessary) to fit your needs. The main extension points are listed here: http://msdn.microsoft.com/en-us/library/ee373852(v=vs.103).aspx. You probably want to take a closer look at IModelGenerationExtension interface. A lot of information about creating extensions for the EF Designer is dated indeed . We have a work item to look at and improve those: https://entityframework.codeplex.com/workitem/1203.
For the usability issues - can you just create a new work item and list all the issues?

Thanks,
Pawel
Apr 25 at 6:55 PM
I did similar stuffs already.
Dealing with prefixes and suffixes used in database naming convention is a real pain because they can't be renamed easily with EDMX.
For that, I will add column aliasing support to my most recent Codeplex project https://entityinterfacegenerator.codeplex.com/