Pergunta

Percebi que parece haver um pouco de hostilidade em relação ao Linq To Entities, especialmente por parte do pessoal da Alt.Net.Eu entendo a resistência a mais programação do tipo "arrastar e soltar", mas pelo que entendi, o Linq To Entities não exige isso.

Atualmente, estamos usando o Linq to SQL e o documento DBML para defini-lo (depois que você obtém mais de uma dúzia de tabelas, o designer é bastante inútil).

Então, por que a mesma abordagem não funcionaria para o Linq To Entities?

Foi útil?

Solução

Eu não acho que seja um ódio pelo ideia disso por si só.É que as pessoas não gostam do implementação disso.

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Outras dicas

Na verdade, uma vez que você começa a se aprofundar nisso, o LTE é completamente inútil para estruturas de nível empresarial.O fato de haver muito pouco suporte à herança (também no LTS) cria muito código redundante.Além disso, voltarei ao LTS (Linq to SQL) porque ele realmente permite definir mapeamentos por meio de atributos em vez de um arquivo.LTE funciona apenas com um arquivo externo.

O ódio do Linq to Entity é muito merecido.Este produto falha em qualquer propósito mais complexo do que as demonstrações idiotas que GU usa em seu blog.A EF está longe de estar pronta para o horário nobre.A Microsoft simplesmente não consegue corrigir os dados no mundo .BLOAT, eles parecem mudar o paradigma dos dados toda vez que o vento sopra.FoxPro existe há 20 anos com o mesmo núcleo de dados básico.Dado que o SQL Server usa grande parte da tecnologia de dados VFP, talvez a MSFT pudesse aprender um pouco sobre a manipulação de dados e linguagens centradas em dados com algo que funcionasse.

Estou bastante convencido dos princípios do Linq to Entities e do Entity Framework em geral, mas tenho reservas sobre sua encarnação atual.Admito francamente que não o usei de forma mais do que autodidata e muito pequena.O nível de flexibilidade ainda não parece existir, mas tenho certeza de que chegará.Um dos evangelistas de tecnologia da MS (ótimo cargo) me disse que a EF era a escolha estratégica da MS para o futuro.Supondo que seja esse o caso, só posso ver as coisas melhorando nesta área.

Também pode haver um pouco de animosidade de “segundo lugar”.EM são muito atrasado para o mercado com L2E, eu mesmo me interessei por ORM há cerca de três anos e o MS não estava em lugar nenhum neste momento.

Muitos de nós já passamos algum tempo aprendendo outro ORM (como o NHibernate) e estamos acostumados com a disponibilidade de um certo nível e tipo de funcionalidade e isso ainda não é evidente no L2E.

Essa animosidade de "segundo lugar" não é notícia velha, para ser honesto, não sei por que a MS não gasta mais tempo apoiando soluções já implementadas, já vimos tudo isso antes com NAnt -> MSBuild e NUnit -> MsTest , pouparia muito tempo e esforço a todos se aceitassem uma das soluções melhores e mais maduras e se esforçassem para apoiá-la, em vez de prepararem as suas próprias soluções o tempo todo.

Eu acrescentaria que a implementação LTE da herança TPT é nada menos que criminosa.Veja minha pergunta aqui.

E já que estou nisso, acredito que muitos especialistas publicados da EF são, pelo menos em parte, cúmplices.Ainda não encontrei nenhum material publicado na EF que alerte contra consultas de tipos básicos.Se eu tentasse no modelo que tenho, o SQL Server simplesmente desiste com a exceção.

Alguma parte da sua declaração SQL é aninhada profundamente.Reescreva a consulta ou divida -a em consultas menores.

Eu adoraria reescrever a consulta, mas o LTE me absolveu desse fardo.Obrigado (^não)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top