EF4 sigue desaparecido componentes muy importantes. Sin embargo, ¿por qué estás esperando el producto perfecto? Nunca va a estar cerca. EF4 es bastante útil incluso si tiene algunos bordes ásperos.
Puede usar SQL y EF4 uno al lado del otro, de modo que si se topa con un escenario en el que EF4 crea un código ineficiente o simplemente no admite algo, siempre puede usar el antiguo ADO.NET. El marco de entidad en realidad admite la construcción de entidades a partir del DataRow
s, por lo que puede fácilmente volver a conectar los resultados de una consulta SQL tan excepcional al flujo de programa normal. Donde EF4 brilla se encuentra en los escenarios más normales donde entra en juego el intellisense de seguridad de tipo &.
El uso del marco entidad implica un poco de una curva de aprendizaje, y cuanto antes comience, mejor. A pesar de el hecho de que EF4 aún no está allí (en mi opinión, de todos modos), diría: ¡adelante! Úselo para algunos rincones pequeños de su aplicación para tener una idea.
puede construir un conexión de la entidad a través de una (sin abrir) SqlConnection
existente que se abre por el EntityConnection
, y el uso de TransactionScope
permite entonces que comparta una sola transacción no distribuida entre EF y ADO. Tomados en conjunto, eso significa que puede usar pequeños bits de EF como reemplazos para consultas normales de ADO, transacciones y todo, como parte de la misma conexión (es decir, sin gastos adicionales desde la perspectiva del servidor).
Supongo que probablemente dependa del DBMS al que desee apuntar –
@vc 74, en realidad, EF no mapea la mayoría de los DBMS que existen. No puse esto como una respuesta, pero creo que EF 4.0 es una mejora importante. Estaba a punto de cambiar a nHibernate después de mucha frustración con EF 3.5, pero lo probé. –
debe ser CWiki. – RPM1984