2009-03-26 18 views
7

tengo objetos de negocio (los desarrolladores a escribir) y algunos sprocs (escribe DBA)Qué ORM es el mejor cuando se utilizan procedimientos almacenados

¿Alguien puede recomendar un buen asignador de objeto a tratar con este tipo de configuración.

Probé con codesmith y nhibernate y tuve problemas. No me importa si mi ORM es gratis o pagado.

+2

No veo qué hay de malo en los sprocs. A veces son solo la cosa. ¿Cómo obtuvieron un nombre tan malo? – Cheeso

+0

Bueno, hay mucha gente a la que no le gustan. Son geniales cuando se trata de ajustar una consulta de rendimiento, pero es una pesadilla para el mantenimiento, como uno de mis proyectos tiene más de 400 sprocs ... Gracias a Dios por la comparación de esquemas en VSTS. – Jojo

+0

Estoy buscando soluciones similares ya que nuestro nuevo líder de tecnología de proyecto * insiste * en que todas las interacciones de código a base de datos se realicen a través de procedimientos almacenados.Cada operación CRUD. Cada consulta. Todo. Pero, él quiere tener un DAL completamente genérico :-) – CMPalmer

Respuesta

7

SubSonic tiene un excelente soporte para sprocs. Va a envolver a cada uno en un método de ayuda y puede recuperar colecciones o entidades fuertemente tipadas de los resultados si lo desea. Muestro una manera de hacerlo en this blog post. Siempre que su sproc devuelva el mismo esquema que SELECT * FROM TableName, funcionará con sus entidades SubSonic.

En cuanto a generar clases basadas en su base de datos, SubSonic genera clases parciales para que pueda ampliarlas según sea necesario. También podría hacer asignaciones de las clases generadas por SubSonic a su modelo real.

+0

al igual que linq2sql: ¿qué hay de los conjuntos de resultados múltiples en 1 procedimiento, posiblemente asignados a entidades? :) – eglasius

+0

¡Simplemente le ganas! –

+0

Creo que solo puede cargar múltiples conjuntos de resultados en conjuntos de datos. –

1

El diseñador LINQ to SQL le otorgará sprocs seguros de tipo como métodos en el objeto DataContext. Puede asignarlos a objetos para operaciones CRUD con bastante facilidad.

De hecho, estoy en el medio de hacer exactamente eso.

+0

El problema que tengo con LINQ to SQL es que Microsoft ha matado bastante el producto. Y tener todo detrás del marco de la Entidad. – Jojo

+0

@Joe realmente no, no tengo el enlace, pero había otra respuesta al respecto, y tenemos una actualización de que hay un equipo con actividades en curso con linq2sql – eglasius

+0

Sería bueno si tuviera el enlace, pero lo haré googlearlo y ver si puedo encontrarlo, lo último que supe es que fue transferido al equipo de ADO, que es un callejón sin salida. – Jojo

2

Dependiendo de la base de datos Entity Framework, o NHibernate son probablemente sus mejores opciones (ejemplos en los enlaces).

+0

No, Nhibernate no funciona bien con sprocs, a menos que me falta algo. Requiere que los artículos devueltos estén en un orden particular y que tengan otras limitaciones. – Jojo

0

El principal problema que veo con esto es que, al usar SP, pierde automáticamente gran parte de la flexibilidad que obtiene al usar ORM, especialmente en la recuperación de información. Debido a esto, estoy seguro de que no podrá usar Todas las características de la mayoría de los ORM.

Por ejemplo, si utiliza linq2sql, tendrá bastante envoltorio para los SP. También puede asignar insertos, eliminaciones y actualizaciones de las entidades generadas a los procedimientos almacenados. Donde pierdes mucho es en la recuperación de la información, tanto porque las consultas están ahora corregidas (y es posible que recuperes más información de la necesaria, es decir, columnas adicionales, o crear muchos SP) y en la carga diferida.

Actualización: Soy más un tipo de linq2sql, pero echaría un vistazo a las suposiciones que está tomando sobre NHibernate. En particular, dudo que forzará el orden de las columnas ya que está configurado con nombres de columna (ver http://nhibernate.info/blog/2008/11/23/populating-entities-from-stored-procedures-with-nhibernate.html). También es compatible con algo que no sé cómo hacer con linq2sql: http://nhibernate.info/blog/2008/11/23/populating-entities-with-associations-from-stored-procedures-with-nhibernate.html. Tenga en cuenta, no me refiero a que el último no es compatible con linq2sql, solo que no sé cómo hacerlo;)

5

subsónico tiene una solución flexible:

class CustomerOrder { 
     private string productName; 

     public string ProductName { 
      get { return productName; } 
      set { productName = value; } 
     } 
     private int total; 

     public int Total { 
      get { return total; } 
      set { total = value; } 
     } 

    } 

continuación:

List<CustomerOrder> orders = Northwind.SPs.CustOrderHist("ALFKI") 
     .ExecuteTypedList<CustomerOrder>(); 

primera mezcla es un sólido "navaja suiza" ORM estilo.

1

Dado que tiene un DBA que escribe los sprocs, creo que lo mejor que puede hacer es trabajar estrechamente con él para descubrir cómo asignar las tablas a los objetos, y cómo estructurar la base de datos para que funciona con tu modelo de dominio No hay nada de malo con los sprocs, solo requieren una estrecha colaboración entre los desarrolladores y los DBA.

Idealmente, el DBA en cuestión es parte de su equipo de proyecto ...

0

Me gusta la manera en que Entity Framework maneja los sprocs en este momento. Puede asociar sprocs con las operaciones crud de una entidad, incluso detecta qué sprocs coinciden con las propiedades de su entidad. El único gran inconveniente en este momento es que si asocias un sproc con una entidad, debes asociar todas las operaciones crud con un sproc.

Este EF Sproc article tiene algunos buenos ejemplos de cómo usar sprocs en EF y también tiene algunos métodos de extensión muy buenos para él.

5

Descargo de responsabilidad: soy el autor de Dapper.


Si usted está buscando un simple asignador de objeto que maneja procsos mapeo de objetos del asunto Dapper es un buen ajuste.

Tenga en cuenta que se envía sin "administración de gráficos", "mapa de identidad", etc. Ofrece un hueso descubierto, solución completa que cubre muchos escenarios que otros ORM no ofrecen.

Sin embargo, ofrece uno de los materializadores de objetos más rápidos que existen, que puede ser 10 veces más rápido que EF o incluso 100 veces más rápido que subsónico en algunos benchmarks.


El trivial:

create proc spGetOrder 
    @Id int 
as 
select * from Orders where Id = @Id 
select * from OrderItems where OrderId = @Id 

pueden ser mapeados con lo siguiente:

var grid = cnn.QueryMultiple("spGetOrder", new {Id = 1}, commandType: CommandType.StoredProcedure); 
var order = grid.Read<Order>(); 
order.Items = grid.Read<OrderItems>(); 

Además cuenta con un apoyo para:

  1. Un multi-Mapper que permite filas individuales a varios objetos
  2. entrada/salida/retorno de soporte parámetro
  3. Una interfaz extensible para el manejo (como TVP)

Así, por ejemplo parámetro específico db:

create proc spGetOrderFancy 
    @Id int, 
    @Message nvarchar(100) output 
as 
set @Message = N'My message' 
select * from Orders join Users u on OwnerId = u.Id where Id = @Id 
select * from OrderItems where OrderId = @Id 
return @@rowcount 

puede ser mapeada con:

var p = new DynamicParameters(); 
p.Add("Id", 1); 
p.Add("Message",direction: ParameterDirection.Output); 
p.Add("rval",direction: ParameterDirection.ReturnValue); 
var grid = cnn.QueryMultiple("spGetOrder", p, commandType: CommandType.StoredProcedure); 
var order = grid.Read<Order,User,Order>((o,u) => {o.Owner = u; return o;}); 
order.Items = grid.Read<OrderItems>(); 

var returnVal = p.Get<int>("rval"); 
var message = p.Get<string>("message"); 

Finalmente, dapper también permitir una implementación de parámetro personalizado:

public interface IDynamicParameters 
{ 
    void AddParameters(IDbCommand command); 
} 

Al implementar esta interfaz, puede indicar qué parámetros desea agregar a su comando. Esto le permite soportar Table-Valued-Params y otras características específicas de DB.

Cuestiones relacionadas