¿Debo utilizar las clases Entity Framework, DataSet o Custom?

Question

Realmente estoy teniendo un momento difícil aquí. Necesito diseñar una "aplicación de escritorio" que use WCF como el canal de comunicación. Es una aplicación de varios niveles (DB y servidor de aplicaciones son lo mismo, el cliente pasa por la nube de Internet).

La aplicación es un poco compleja (en términos de SQL y lógica de código) luego las aplicaciones LOB habituales, pero el concepto es el mismo: leer de DB, actualizar a DB, manejar concurrencia etc. Mi problema es que ahora con Entity Framework a la vista, no puedo decidir qué camino seguir: ¿Debería usar Entity Framework, Dataset o Custom Classes?

Como entiendo por Entity Framework, creará el mapeo de objetos de mis tablas DB JUNTO CON los scripts CRUD también. Eso está muy bien para CRUD simple, pero la mayoría de las veces el "Seleccionar" es complejo y requiere un SQL personalizado. Entiendo que puedo usar procedimientos almacenados en EF (no me gusta SP por cierto, no sé por qué, me gusta codificar mi SQL en el DAL a mano, me siento más seguro y cómodo de esa manera).

Con DataSet, utilizaré mis SQL personalizados y completaré en el conjunto de datos. Con las clases personalizadas (objetos para tablas de BD) completaré mis SQL personalizados en esas clases personalizadas (colecciones y listas, etc.). Quiero usar EF, pero no me siento seguro al implementar una aplicación cuyo SQL no he escrito y no puedo ver en el código. Me estoy perdiendo de algo.

Cualquier ayuda en este sentido sería muy apreciada.

Xeshu

Answer 1

Estoy de acuerdo con Marc G. 100% - DataSets es una mierda, especialmente en un escenario WCF (agregan mucha sobrecarga para manejar la manipulación de datos en memoria) - no los use. Están bien para principiantes y para aplicaciones de escritorio de dos niveles a pequeña escala, pero no los usaría en una aplicación profesional seria.

Básicamente, su pregunta se reduce a cómo se transforman las filas de la base de datos en algo remoto en WCF. Esto significa algún tipo de mapeo, ya sea que lo hagas tú mismo, utilizando DataReaders y luego insertando todos los datos en las clases de WCF [DataContract]; puedes hacerlo, te brinda el máximo control, pero también es tedioso, engorroso y propenso a errores.

O bien, deje que un ORM ya hecho funcione para usted: elija entre Linq-to-SQL (excelente, fácil de usar, flexible, pero solo SQL Server), EF v4 (out by Marzo de 2010 - se ve muy prometedor, muy flexible) o cualquier otro ORM, realmente - lo que más se ajuste a sus necesidades.

Otros competidores serios en el espacio de ORM podrían incluir Subsonic 3.0 y NHibernate (entre muchos otros).

Para resumir:

• olvidarse de conjuntos de datos
• ya sea que tienen el control del 100% y para la asignación entre SQL y sus objetos usted mismo
• que vamos a algún ORM capaz manejar que (Linq- a-SQL, v4 EF, subsónico, NHibernate et al) - que uno realmente no importa mucho, es decir, que también es una cuestión de preferencia personal y la codificación de estilo

Answer 2

no puedo abogar conjuntos de datos, especialmente en un entorno SOA como WCF - que va a trabajar, pero para la mayoría de las razones equivocadas. Simplemente no son portátiles, y la OMI realmente no "funciona" sobre los límites del servicio. Por supuesto, IMO no funcionan en la mayoría de los otros escenarios también ;-p

Entonces, todo se reduce a la cantidad de tubería que desea hacer. La mayoría de los ORM crearán tipos serializables WCF para usted; personalmente Usaría LINQ-to-SQL en este momento; es a la vez más simple y más completo que EF, aunque EF 4.0 está destinado a ser mucho mejor que EF en 3.5sp1. Puede usar un TSQL personalizado (a través de ExecuteQuery, que aún hace la asignación de vuelta a los objetos), pero tiendo a usar ya sea SPROC (para consultas complejas) o consultas generadas por LINQ (para solicitudes simples).

Escribir los tipos tú también está bien, y funcionará con NHibernate etc. Tantas opciones.

Answer 3

Mientras EF utiliza WCF y por lo Unds muy prometedor, debe considerar el esfuerzo para ponerse a la velocidad con él. Especialmente cuando se hacen cosas no triviales, el diseñador de VS2008 ya no puede abrir el modelo y debe codificar su modelo en xml.

También tenga en cuenta que EF trabaja en un nivel de abstracción muy alto. Debido a law of leaky abstractions no es tan brillante como debería ser :) A la inversa, eso significa que tiene que lidiar con sentencias SQL muy locas y difíciles de leer que se envían a su base de datos cuando se trata de problemas de resolución de problemas/rendimiento.