ADO.NET Entity Framework o ADO.NET

Question

estoy empezando un nuevo proyecto basado en ASP.NET y el servidor de Windows.

La aplicación está prevista a ser bastante grande y servir gran cantidad de clientes que tiran y actualización de alta frecuencia. cambio de datos.

He creado anteriormente proyectos con Linq-To-Sql o con Ado.Net.

Mi plan para este proyecto es utilizar VS2010 y el nuevo marco EF4.

• Sería bueno escuchar otras opciones programadores sobre el desarrollo con Entity Framework

• pros y los contras de experiencia previa?

• ¿Cree EF4 está listo para producción?

• ¿Debo correr el riesgo o simplemente quedarme con el viejo y bueno ADO.NET?

Answer 1

Si EF4 está realmente listo para la producción es un poco difícil de decir, ya que aún no se ha lanzado oficialmente .... pero todas las experiencias e informes preliminares parecen indicar que es bastante bueno.

Sin embargo: Es necesario tomar en consideración lo que EF está tratando de resolver; es un enfoque de dos capas, una capa se asigna a su esquema de almacenamiento físico en su base de datos (y es compatible con múltiples backends), y la segunda capa es su modelo conceptual contra el que programa. Y, por supuesto, existe la necesidad de un mapeo entre esas dos capas.

Así EF4 es ideal si tiene una gran cantidad de tablas, si tiene varios backends para admitir, si necesita poder asignar un esquema físico a un esquema conceptual diferente, y así sucesivamente. Es ideal para aplicaciones complejas de nivel empresarial.

pero eso tiene un costo - esas capas adicionales tienen un impacto en el rendimiento, la complejidad, facilidad de mantenimiento. Si necesita esas características, estará encantado de pagar ese precio, sin dudas. ¿Pero lo necesitas?

Claro, podría volver a la línea recta ADO.NET, pero ¿realmente quiere juguetear con DataTables, DataRows y constructos sin tipo Row["RowName"] de nuevo? ¿¿¿DE VERDAD???

Así que mi recomendación sería la siguiente:

• Si sólo necesita SQL Server como su base de
• si tiene una correspondencia bastante simple y directo de la mesa de una base de datos con objeto una entidad en su modelo

luego: use Linq-to-SQL! ¿¿Por qué no?? Todavía es totalmente compatible con Microsoft en .NET 4 - diablos, incluso lo hicieron bugfixes and added a few bits and pieces - es rápido, es eficiente, es delgado y malo - ¿por qué no?

Answer 2

EF 4 ahora es más similar a LINQ to SQL, en las buenas formas; tiene las teclas FK justo en el objeto, tiene métodos de agregar directamente en los conjuntos de objetos, y muchas otras características agradables. El diseñador ha mejorado mucho, y la ventaja más importante es que funciona con SQL y Oracle, y tal vez algunos otros (siempre que el proveedor lo admita) en lugar de LINQ to SQL con solo SQL Server.

EF es el futuro; los servicios de datos ADO.NET son un complemento de servicio web, además de admitir la generación POCO y T4, y cualquier característica nueva admitirá esto (LINQ to SQL es solo de mantenimiento, y los conjuntos de datos ya no recibirán ningún cambio).

HTH.

Answer 3

Mi consejo es usar ambos. Al principio pensé que solo usaría linq para sql y nunca tendría que tocar ado.net nunca más (lo que me hizo feliz jajaja).

Ahora estoy usando ambos porque algunas cosas linq a sql (y cualquier ORM como EF) no pueden hacer. Tuve que hacer algunas inserciones masivas y lo hice primero con linq a sql y para hacer 500 registros tardé más de 6 minutos (2 minutos para las reglas de validación que el resto estaba insertando en el db).

lo cambié a SQL copia masiva y ahora se ha reducido a segundos 2min y 4 (4 segundos para hacer todas las inserciones)

Pero como dijo marc_s Realmente no quería ver alrededor de DataTables, DataRows, y Row sin tipo ["RowName"].

Digamos que mi tabla tenía 10 columnas y se llamaba Tabla A. Lo que hice fue usar linq a sql e hice una clase de tabla A (nuevo objeto TableA()) y la llené con datos. Luego pasaría este objeto a un método que creó el datarow.

Así que linq to sql me ahorró algo de tiempo porque probablemente habría hecho una clase ya que no hubiera querido pasar 10 parámetros al método que hace la fila de datos. También creo que da un poco de tipografía, ya que tienes que pasar el objeto correcto para usar ese método, por lo que hay menos posibilidades de pasar los datos incorrectos.

Finalmente, puede seguir utilizando linq a sql para llamar a los procedimientos almacenados y eso es como una línea de código.

Así que usaría ambos cuando notara que linq to sql (o en su caso EF) es lento, entonces simplemente escriba un SP y llámelo a través de EF. Si necesita hacer un estilo directo de ado.net, evalúe lo que necesita hacer, tal vez pueda usar EF para la mayoría del código (para que al menos pueda trabajar con objetos) y solo para esa pequeña porción de ado.net, algo de lo que hice con copia a granel sql.