2011-12-22 14 views
5

Tengo curiosidad acerca de las mejores prácticas al desarrollar la aplicación n-tier con el servicio Linq-to-SQL y WCF.Servicio Linq-to-SQL y WCF: objetos de transferencia de datos

En particular, me interesa, por ejemplo, cómo volver a los datos de nivel de presentación de dos tablas relacionadas. Supongamos ahora la situación (muy simplificada):

base de datos tiene tablas:

  • Orders (id, OrderName)
  • OrderDetails (id, orderid, DetailName)

de etapa intermedia tiene métodos CRUD para OrderDetails. Por lo tanto, necesito tener un modo de reconstruir la entidad para adjuntarla al contexto de la actualización o insertarla cuando vuelva de la capa de presentación.

En la capa de presentación, necesito mostrar la lista de OrderDetails con el correspondiente OrderName de la tabla padre.

Existen dos enfoque para las clases, que regresó del servicio:

  1. Uso DTO clase personalizada que va a encapsular los datos de ambas tablas y proyección:

    class OrderDetailDTO 
    { 
        public int Id { get; set; } 
        public string DetailName { get; set; } 
        public string OrderName { get; set; } 
    } 
    IEnumerable<OrderDetailDTO> GetOrderDetails() 
    { 
        var db = new LinqDataContext(); 
        return (from od in db.OrderDetails 
          select new OrderDetailDTO 
          { 
          Id = od.id, 
          DetailName = od.DetailName, 
          OrderName = od.Order.OrderName 
          }).ToList(); 
    } 
    

    Contras: necesidad de asignar cada campo que es importante para la capa de presentación en ambos sentidos (al devolver datos y al crear una entidad nueva para adjuntar al contexto, cuando los datos vuelven de la capa de presentación)

  2. uso personalizado LINQ a SQL entidad clase parcial:

    partial class OrderDetail 
    { 
        [DataMember] 
        public string OrderName 
        { 
        get 
        { 
         return this.Order.OrderName // return value from related entity 
        } 
        set {} 
        } 
    } 
    
    IEnumerable<OrderDetail> GetOrderDetails() 
    { 
        var db = new LinqDataContext(); 
        var loadOptions = new DataLoadOptions(); 
        loadOptions.LoadWith<OrderDetail>(item => item.Order); 
        db.LoadOptions = options; 
        return (from od in db.OrderDetails 
          select od).ToList(); 
    } 
    

Contras: consulta la base de datos incluirá todas las columnas de Orders mesa, LINQ to SQL se materializará entidad Order conjunto, aunque solo necesita un campo de eso.

Perdón por una historia tan larga. Puede ser que me haya perdido algo? Apreciaremos cualquier sugerencia.

Respuesta

3

yo diría uso DTO y AutoMapper, no es una buena idea para exponer entidad DB como DataContract

+0

O EmitMapper, dicen que tiene un rendimiento mucho mejor. – Monsignor

+0

¿Por qué no EF? Muy interesante –

1

¿Es el uso de LINQ to SQL un requisito para usted o que se encuentran todavía en fase de diseño donde se puede elegir tecnologías? Si es el último, sugeriría usar Entity Framework con Entidades de seguimiento automático (STE). Que cuando recupere la entidad del cliente, los STE manejarán automáticamente todos los cambios del cliente, solo tendrá que llamar a Guardar. Incluir entidades relacionadas también es fácil: (...some query...).Orders.Include(c => c.OrderDetails)

+0

Desafortunadamente estoy en etapa de desarrollo. Estaba pensando en migrar a EF, pero no es una opción por un momento debido al límite de tiempo. – Harm

Cuestiones relacionadas