2010-09-29 23 views
10

Para un ERP básico (DB con alrededor de 150 tablas, aplicación WinForm) que se ejecutaría en una red LAN clásica (1 servidor y hasta 25 clientes), ¿recomendaría EF4 o DataSet?Entity framework 4 o DataSet?

¡LINQ2SQL NO es una opción!

+0

Al elegir estas cosas, necesitamos conocer los requisitos de rendimiento y cómo se almacenan/detallan los datos en la base de datos. ¿Puede compartir una palabra o dos sobre Performance and DB Table Structure? – Nix

+0

Es una aplicación clásica de escritorio (más OLTP/menos OLAP) con base de datos MSSQL2008X en backend (la mayor parte de la lógica está integrada en procedimientos y relaciones almacenados) sobre ventas, compras, pedidos, inventario, producción pero a pequeña escala. – EmirZ

+0

Puede usar procedimientos almacenados con EF4 - asignar SP a la creación de objetos. Pero incluso si no quieres usar EF4, aún resistiría el uso de DataSets. Los objetos son mucho más fáciles de manejar. –

Respuesta

6

EF4. DataSet es una tecnología antigua, EF es en muchos sentidos una reacción a los problemas con los conjuntos de datos.

Recientemente creamos una aplicación, donde parte de ella era operaciones CRUD en 80 tablas. Antes de EF, hubiéramos usado Enterprise Library y DataSets. Hubiéramos estimado 1 hora por mesa para escribir la operación CRUD y la prueba unitaria. Con EF esto fue reemplazado principalmente con código autogenerado.

+0

¿Tiene pruebas de unidad/integración para su código EF CRUD? –

+1

@Michael Maddox, sí, en realidad es una prueba de integración, ya que llega a la base de datos. Lo colocamos dentro de un alcance de transacción para que no cambie la base de datos. Básicamente comprueban que nadie cambie los scripts que crean la base de datos sin actualizar también el modelo de EF. Con un primer acercamiento al código esto sería un poco diferente. –

+0

¿Cuántos registros carga? ¿Es una opción viable cargar 20000 registros (filas) en una cuadrícula con marco de entidad? – surfmuggle

4

Puede elegir EF según la lógica de la aplicación, EF puede darle más opciones, pero creo que no podemos decidir en función del número de tablas.

Comprobar este artículo que le ayudará a decidir:

Why use the Entity Framework?

También puedes ver este bonito vídeo: Data Development GPS: Guidance for Choosing the Right Data Access Technology for Your Application Today

+0

videoLink está muerto, vaya aquí para obtener una nueva dirección: http: //channel9.msdn.com/Events/TechEd/NorthAmerica/2010/DEV324 – ruedi

2

que es una cuestión de composición bastante abierta con no apoyar cantidad de información. Hay un montón de factores involucrados en este tipo de decisión. ¿Es solo tu desarrollo o un equipo? De cualquier manera, ¿qué experiencia tienes con EF? Si no tienes mucha experiencia y hay una línea de tiempo ajustada, puede ser más rápido realizar el trabajo con conjuntos de datos.

Dejando de lado estos tipos de preguntas, soy un gran admirador de ORM y creo que hace la vida más fácil a largo plazo. Pero tiene una curva de aprendizaje si no está familiarizado con algunos de los conceptos y especialmente con los errores (como los problemas Select N + 1).

+0

Soy el único desarrollador ... ¡y pls leí el comentario anterior! – EmirZ

+0

Es una aplicación clásica de escritorio (más OLTP/menos OLAP) con base de datos MSSQL2008X en back-end (la mayor parte de la lógica está integrada en procedimientos y relaciones almacenados) sobre ventas, compras, pedidos, inventario, producción pero a pequeña escala. – EmirZ

2

Incluso si no elige EF4, los conjuntos de datos no son la única opción.

Me gustaría mucho más bien trabajo con POCOs que DataSets.

Los objetos son mucho más fáciles de manipular que los DataSets. Por ejemplo, validar datos en un POCO es trivial y fácil de mantener. En un DataSet no es ninguno de los dos.

Cuestiones relacionadas