2010-05-23 22 views
9

Soy nuevo en CSLA y Entity Framework. Estoy creando una nueva aplicación CSLA/Silverlight que reemplazará un sistema Win32 C++ de 12 años. El sistema anterior usa una biblioteca de objetos comerciales DCOM personalizada y utiliza ODBC para llegar a SQL Server. El nuevo sistema no reemplazará inmediatamente el sistema anterior; deben coexistir con la misma base de datos en los próximos años.debería usar Entity Framework en lugar de raw ADO.NET

Al principio pensé que EF era el camino a seguir, ya que es el último y el mejor. Después de hacer un pequeño modelo EF y solo 2 objetos raíz editables de CSLA (eventualmente tendré cientos de objetos ya que mi base de datos tiene más de 800 tablas) estoy cuestionando seriamente el uso de EF.

En el sistema actual, tengo la necesidad muchas veces de hacer un ajuste preciso del rendimiento de las consultas que puedo hacer debido al 100% de control de SQL generado. Pero parece que en EF sucede tanto detrás de escena que pierdo ese control. Artículo como http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html no ayuda mi impresión de EF.

Parece que a las personas les gusta EF debido a LINQ to EF pero dado que mi criterio se pasa entre el cliente y el servidor como objeto de criterio, parece que podría generar consultas con la misma facilidad sin LINQ. Entiendo en WCF RIA que hay una proyección de consultas (o algo así) donde puedo hacer LINQ del lado del cliente que se mueve al servidor antes de la traducción al SQL real, así que en ese caso puedo ver el beneficio de EF, pero no en CSLA .

Si utilizo ADO.NET sin procesar, ¿lamentaré mi decisión dentro de 5 años?

¿Alguien más ha hecho esta elección recientemente y de qué manera fuiste?

+0

Gran pregunta ... Estaba a punto de hacer una muy similar. Me he estado preguntando cuál es la ventaja de EF sobre la velocidad y el control de ADO.NET ... – Walter

Respuesta

7

En su caso, todavía elegiría EF sobre hacerlo todo a mano.

¿Por qué? EF - especialmente en .NET 4 - ha madurado considerablemente. Le permitirá hacer la mayoría de las operaciones de su base de datos mucho más fácilmente y con mucho menos código que si tuviera que codificar manualmente su código de acceso a datos.

Y en los casos en que necesita el máximo rendimiento absoluto, siempre puede conectar procedimientos almacenados para insertar, actualizar y eliminar que EF4 usará en lugar del comportamiento predeterminado de crear las declaraciones SQL sobre la marcha.

EF4 tiene una integración mucho mejor proc almacenado, y esto realmente se abre lo mejor de ambos mundos:

  • utiliza la alta productividad de EF para los casos 80% en el rendimiento no es primordial
  • afinar y artesanía almacena procs para el 20% restante y conectarlos a EF4

Ver algunos recursos:

2

Usted parece tener una mezcla de requisitos y una mezcla de soluciones.

Normalmente califico cada requisito con un esencial, agradable de tener, no esencial. Y luego mira lo que funciona.

Estoy de acuerdo con lo que ha dicho @marc_s, puede tener lo mejor de ambos mundos.

La única otra cosa que diría es que si esta solución es a estar allí por los próximos 5 años, ¿ha considerado la Unidad de Pruebas?

Hay plentyofexamples sobre cómo configurar esto usando EF. (Yo personalmente evito ADO.Net sólo porque la separaba de las preocupaciones es tan complicado para pruebas unitarias.)

No hay una solución fácil. Escogería una función en su proyecto que le tomaría un día o dos para hacerlo. Pruebe los diferentes métodos (raw sql, EF, EF + Stored Procs) y vea qué funciona.

0

Tome una mirada objetiva a CSLA - invocar el 'DataPortal' y echa un vistazo a la pila de llamadas.

A continuación, poner esas clases en un servidor de compilación de CI que almacena los datos de tiempo de ejecución y proporciona un gráfico de dispersión a través de una serie de carreras.

A continuación, mire el código que se crea. Pregúntese cómo puede usar cosas como la inyección de dependencia a la luz de las clases que dependen de creadores estáticos con constructores privados/protegidos.

A continuación, echar un vistazo a la cantidad responsabilidades clases de la 'CSLA' adquieren.

Finalmente preguntarse si la creación de objetos con diferentes constructores por el medio ambiente tiene sentido, y se pregunta cómo se pondrá a prueba la unidad de aquellos.

+0

Parece que no le gusta CSLA por algunos motivos válidos y algunos no tan válidos en mi caso. ¿Qué recomiendas para un marco obj de bus que tenga: facilidad de uso de Silverlight y .NET (WebForms, WinForms, WPF, SOA personalizado), reglas del lado del servidor y del lado del cliente (configurables por el usuario y codificadas), configurable por usuario por propiedad/por Control de seguridad CRUD, configurable por el usuario por valores de campo predeterminados de propiedad, y varias implementaciones de n niveles para trabajar en diferentes entornos de clientes. Necesito todo esto y más. Estoy construyendo una aplicación, no un marco y no quiero reinventar nada. Sugerencias? Gracias. –

+0

No estoy seguro de lo que quiere decir con 'dislike csla'. El código es código. He tomado su pregunta original para estar en csla y EF, pero la redacción de sus requisitos muestra que ya ha ajustado el problema a la csla vernacular. –

Cuestiones relacionadas