Qué estrategia de acceso a datos para una aplicación grande

Question

Estoy a punto de embarcarme en una reescritura de una aplicación VB6 en .NET 3.5sp1. La aplicación VB6 está bastante bien escrita y la capa de datos se basa completamente en procedimientos almacenados. Me gustaría ir con algo automatizado como Linq2SQL / Entity Framework / NHibernate / SubSonic. Es cierto que no he usado ninguna de estas herramientas en nada más que proyectos desechables.

El problema potencial que temo tener con todas estas opciones es la velocidad. Por ejemplo, en este momento para recuperar una sola fila (o la lista completa), uso el siguiente sproc:

ALTER PROCEDURE [dbo].[lst_Customers]
 @intID     INT = NULL
,@chvName   VARCHAR(100) = NULL
AS

SELECT   Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
 AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))
ORDER BY name

Para recuperar una sola fila en Linq2SQL / Entity Framework / NHibernate / SubSonic, ¿estas soluciones tendrían que llevar la lista completa al cliente y encontrar la fila que necesito?

Entonces, ¿cuál es el consenso para la estrategia de acceso a datos para una aplicación con un gran dominio de datos?

Answer 1

Voy a jugar al abogado del diablo y te recomiendo que al menos consideres seguir con los procedimientos almacenados. Estos representan una porción de código que no tiene que volver a escribir y depurar. Este artículo de nuestro propio [tm] Joel Spolsky ofrece un argumento coherente para evitando reescrituras completas.

Dado un proyecto 'greenfield', puede usar lo que quiera, y un mapeador O / R podría ser una buena opción. Sin embargo, ya ha declarado que la aplicación VB6 está bien escrita. Si los sprocs están bien escritos, obtienes parte de tu aplicación de forma gratuita y ya está depurada, además de que puedes reciclar el esquema de la base de datos y evitar la mayor parte del dolor de la migración de datos.

Fowler Patrones de arquitectura de aplicaciones empresariales debería darle algunos buenos consejos para diseñando una capa de acceso a datos que jugará bien con los procedimientos almacenados sin causar problemas de mantenimiento.

Esto se hace con bastante frecuencia en las aplicaciones Oracle / Java. Muchas aplicaciones de Oracle heredadas tienen grandes cuerpos de código de procedimiento almacenado en PL / SQL; esta era una arquitectura estándar en los días cliente-servidor de Oracle Forms. Es una práctica común escribir un contenedor para las sprocs en Java y construir la interfaz de usuario en la parte superior del contenedor.

Uno de los otros carteles mencionó que Subsonic puede generar envoltorios para los sprocs.

Una vez tuve la oportunidad de hacer un hack de diccionario de datos que generó un contenedor Java / JDBC de prueba de concepto para PL / SQL sprocs - IIRC solo tomó un día más o menos. Dado que no es tan difícil de hacer, me sorprendería descubrir que no hay muchas opciones en las cosas que puede sacar de la plataforma para hacer esto. En un apuro, escribir el tuyo tampoco es tan difícil.

Answer 2

No puedo hablar sobre Linq-to-SQL, Entity Framework ni NHibernate, pero estoy enamorado de SubSonic. Mi experiencia con él ha sido abrumadoramente positiva.

La forma en que funcionan estas herramientas, en general, es que crean consultas parametrizadas para usted en código administrado, encapsulan ese acceso en clases y luego exponen esas clases a sus aplicaciones. Roca DAL totalmente generada.

Al usar las consultas parametrizadas, le preocupa que puedan "tener que llevar toda la lista al cliente y encontrar la fila que necesito". es manejado. Admiten cláusulas where y otros filtros para obtener solo las filas que necesita. Puede hacer el equivalente de select * from foo , pero no está atascado en ese modo.

Dicho esto, SubSonic hace, cuando se usa fuera de la caja para el acceso directo a la tabla / vista, derribar filas enteras, lo que podría ser una desventaja en algunos escenarios. Sin embargo, su acceso a través de los procs almacenados no es un problema: no puedo hablar con los demás, pero SubSonic ayuda a crear una clase SPs que encapsula todos sus procs, lo que le permite llamarlos como métodos, y devolver los DataTable apropiados, que luego puede analizar manualmente según sea necesario. También hay formas de inicializar listas de clases DAL de los procesos, por lo que si el proceso devuelve un conjunto de datos que coincide directamente con una tabla / vista, aún puede tener la sintaxis más limpia sin procesamiento manual.

(SubSonic, por cierto, me curó de '' procs para todo ''. Ahora, por lo general, casi no paso tiempo haciendo CRUD procs como lo hice en el pasado, y solo termino usándolos para informes complicados. Pero su kilometraje puede, y de hecho, variará.)

Answer 3

Recomendaría usar SubSonic para generar todo el código para acceder a sus procesos almacenados existentes, de esta manera reduce las posibilidades de regresión debido a una nueva capa de acceso a datos. Se puede acceder a cualquier nueva característica mediante el uso de las clases ActiveRecord que genera SubSonic. Este me parece ser el enfoque más seguro y rápido para proceder,

No estoy de acuerdo con la recomendación de NHibernate porque no es muy adecuada para trabajar con procedimientos almacenados.

Answer 4

Intentamos usar el marco de la entidad como un orm y encontramos múltiples problemas al tratar de usarlo con el Desarrollo Dirigido por Dominio. Linq to Sql también tiene algunas limitaciones y Microsoft va a dejar de admitirlo en la próxima versión, creo.

Answer 5

Si las consultas están en procedimientos almacenados, hay una buena posibilidad de que ya estén bien optimizadas. Y probablemente hacen un uso liberal de las expresiones SQL para JOINS, subconsultas, etc.

Duplicar ese tipo de eficiencia y expresividad, con precisión , con una capa de abstracción de tipo ORM, sería un desafío, especialmente si no está totalmente familiarizado con las herramientas.

Siempre puede refactorizar las consultas después de obtener el resto de la aplicación directamente. Y el mundo de ORM está cambiando lo suficientemente rápido como para que las opciones sean diferentes cuando llegues allí.

Answer 6

SubSonic, incluso según Rob Connery, uno de los autores, está escrito más para soportar el desarrollo rápido de aplicaciones y menos sobre aplicaciones grandes. Yo diría que vaya con NHibernate ya que encontrará el mayor apoyo de la comunidad, así como un marco probado y probado. Puede obtener buena información de www.dimecasts.net sobre la configuración de sus cosas de NHibernate.