Entity Framework: Como posso permitir que um uma tabela por herança de classe com um campo rowversion?

Question

Por que não posso definir um membro com o mesmo nome em subclasses? Eu tenho uma tabela por herança de classe com um campo rowversion timestamp em cada mesa. Parece que o designer Entidade deve permitir isso e usar a palavra-chave new na propriedade para que isso aconteça. Qual é a solução? Como posso especificar o mesmo campo em uma cadeia de herança com valores diferentes se eu não puder usar new? Isso pode ser verdade para outros bancos de dados que têm rowguids, modifiedbys, modifieddates, etc.

Editar:. Eu acho que a maneira lógica de fazê-lo seria apenas para renomear a referência para o campo, ou seja PersonRowversion na classe Student que decends de Person

Am I faltando um pedaço de EF que pode rastrear esses tipos de campos automaticamente embora?

Answer 1

Porque uma classe não pode ter dois membros com o mesmo nome. "Novo" não vai fazer o que quiser. "Novo" esconde o membro herdado; ele não lhe dá dois membros diferentes com o mesmo nome. Então, se o código gerado usado "novo", então você nunca seria capaz de acessar o valor na "tabela pai" do seu código C #. É bom para ambas as tabelas de banco de dados para ter duas colunas com o mesmo nome, mas você precisa para renomear os nomes de coluna duplicados em seu modelo conceitual quando duas tabelas constituem uma classe.

Em termos de "data de modificação", etc., geralmente você só precisa de um. Se você tem um super tipo de animal e um subtipo de Cão, o Entity Framework considera uma atualização para o " parte animal" ou a 'parte cão' do tipo a ser uma atualização para toda a instância, como C # faz.

Lembre-se que o modelo conceitual eo modelo de armazenamento são coisas diferentes, e jogar com regras diferentes. Tenha cuidado de pensar em estritamente OO ou termos estritamente relacionais quando se trabalha em seu modelo de entidade. Dentro do modelo de entidade, você está colmatar dois mundos. Como eu escreveu em outro lugar :

Uma das barreiras mentais que você tem que superar na concepção de mapeamento relacional um bom objeto é a tendência a pensar principalmente em orientadosa termos ou termos relacionais, o que se adapte a sua personalidade. Um mapeamento relacional objeto bom, embora, incorpora tanto um bom modelo de objecto e um bom modelo relacional. Por exemplo, digamos que você tem um banco de dados com uma mesa para Pessoas e tabelas relacionados para funcionários e clientes. Uma única pessoa pode ter um registro em todas as três tabelas. Agora, a partir de um ponto estritamente de vista relacional, você poderia construir uma visão de banco de dados para os funcionários e outra para os clientes, os quais informações incorporam da tabela Pessoas. Ao usar um um ponto de vista ou de outra, você pode temporariamente pensar de uma pessoa individual como "apenas" um funcionário ou "apenas" um cliente, mesmo que você saiba que eles são ambos. Então, alguém que vem dessa visão de mundo pode ser tentado a fazer um mapeamento OO, onde funcionários e cliente são as duas subclasses (diretas) da pessoa. Mas isso não funciona com os dados que temos; pois uma única pessoa tem ambos os registros de empregados e clientes (e desde que nenhuma instância Pessoa pode ser do empregado concreto subtipo eo Cliente simultaneamente), a relação OO entre Pessoa e empregado precisa ser composição em vez de herança, e da mesma forma para Pessoa e cliente.