Pregunta

He notado que parece haber bastante hostilidad hacia Linq To Entities, particularmente por parte de la gente de Alt.Net.Entiendo la resistencia a una mayor programación de "arrastrar y soltar", pero según tengo entendido, Linq To Entities no la requiere.

Actualmente estamos usando Linq to SQL y estamos usando el documento DBML para definirlo (una vez que obtienes más de una docena de tablas, el diseñador es bastante inútil).

Entonces, ¿por qué no funcionaría el mismo enfoque para Linq To Entities?

¿Fue útil?

Solución

No creo que sea un odio hacia el idea de ello per se.Es sólo que a la gente no le gusta implementación de ello.

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

Otros consejos

En realidad, una vez que empiezas a profundizar en ello, LTE es completamente inútil para marcos de nivel empresarial.El hecho de que haya muy poco soporte de herencia (también en LTS) genera una gran cantidad de código redundante.Además, volveré a LTS (Linq to SQL) porque en realidad le permite definir asignaciones a través de Atributos en lugar de un Archivo.LTE sólo funciona con un archivo externo.

El odio de Linq a Entity es muy merecido.Este producto falla en cualquier propósito más complejo que las demostraciones poco convincentes para las que GU lo usa en su blog.EF está lejos de estar listo para el horario de máxima audiencia.Microsoft simplemente no puede obtener datos correctos en el mundo .BLOAT, parece que cambia el paradigma de datos cada vez que sopla el viento.FoxPro existe desde hace 20 años con el mismo núcleo de datos básico.Dado que SQL Server utiliza gran parte de la tecnología de datos VFP, tal vez MSFT pueda aprender un poco sobre la manipulación de datos y lenguajes centrados en datos a partir de algo que funcione.

Estoy bastante convencido de los principios de Linq to Entities y de Entity Framework en general, pero tengo reservas sobre su encarnación actual.Sin embargo, admito libremente que no lo he utilizado más que de forma autodidacta y muy pequeña.El nivel de flexibilidad no parece haber llegado todavía, pero estoy seguro de que llegará.Uno de los evangelistas de la tecnología de MS (gran título de trabajo) me dijo que EF era la opción estratégica de MS para el futuro.Suponiendo que este sea el caso, sólo puedo ver que las cosas mejorarán en este ámbito.

También podría haber un poco de animosidad por el "segundo lugar".EM son muy Llegué tarde al mercado con L2E, yo mismo me interesé en ORM hace unos tres años y MS no aparecía por ningún lado en este momento.

Muchos de nosotros ya hemos dedicado tiempo a aprender otro ORM (como NHibernate) y estamos acostumbrados a que cierto nivel y tipo de funcionalidad esté disponible y esto aún no es evidente en L2E.

Para ser honesto, esta animosidad por el "segundo lugar" no es una vieja noticia. No sé por qué MS no dedica más tiempo a respaldar las soluciones que ya existen, hemos visto todo esto antes con NAnt -> MSBuild y NUnit -> MsTest , les ahorraría a todos mucho tiempo y esfuerzo si simplemente aceptaran una de las mejores y más maduras soluciones y se esforzaran por respaldarla en lugar de elaborar la suya propia todo el tiempo.

Yo añadiría que la implementación de LTE de la herencia TPT es nada menos que criminal.ver mi pregunta aquí.

Y ya que estoy en ello, creo que los muchos expertos publicados en EF son al menos en parte cómplices.Todavía tengo que encontrar algún material publicado sobre EF que advierta contra consultas de tipos básicos.Si tuviera que probarlo en el modelo que tengo, SQL Server simplemente se da por vencido con la excepción.

Alguna parte de su declaración SQL está anidada demasiado profundamente.Reescribe la consulta o divídala en consultas más pequeñas.

Me encantaría reescribir la consulta, pero LTE me absolvió de esa carga.Gracias (^no)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top