The DbContext of my application's Entity Framework setup (which I will refer to as ApplicationContext, the name of our derived type) contains classes for all of the tables in our SQL Server database, rather than having them spread out across multiple DbContext classes. One of the issues we've run into is, because EF uses reflection to map the entity classes to their table/view counterparts, all of those classes must be in the same namespace as the ApplicationContext (if this is incorrect, please let me know).

As a result, when two SQL tables in different schemas share the same name, naming the EF classes becomes a problem.

Let's say I have two tables: FranchisorSetup.ProposalTextBlocks and ProposalManagement.ProposalTextBlocks. Because of the limitation of EF I mentioned earlier, both of those entity classes must exist in the same namespace if they are to both be a part of ApplicationContext.

My EF class definition might look like this:

namespace MyApp.DAL.EF
    public class ProposalTextBlock { // class definition }

This works fine for one table, but my second table, ProposalManagement.ProposalTextBlocks, also needs to be named ProposalTextBlock. This will give me a compiler error, as that class name is already being taken by the first table.

Using a different DbContext for each schema would solve this particular issue, but create a host of others. What is a standard way of solving this issue?

  • 1
    I don't think the class name has to match the table name... It can be whatever you want. Like described in stackoverflow.com/questions/20184644/… – Eric King Aug 22 '17 at 20:07
  • True, which is what I'm using the [Table] data annotation for. I could always fudge the names, but the point of my post is to see if there is a best practice for handling this situation without having to do that. In fact, it seems so basic and common that I'm curious as to why I haven't been able to find a standard solution out there – Jacob Stamm Aug 23 '17 at 14:51
  • 1
    Ahh, I see. I'm not sure I see why you're hesitant here... The standard solution would be to find a better, unique names for your classes. I was thrown by the "but my second table, ProposalManagement.ProposalTextBlocks, also needs to be named ProposalTextBlock". In reality, neither of them need to be named such. – Eric King Aug 23 '17 at 17:31
  • 1
    I get ya. We ended up appending the schema as a prefix to the class names. Ends up being really long, but at least there's no ambiguity. – Jacob Stamm Aug 23 '17 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.