tablas - consultas linq c# ejemplos

LINQ a objetos de entidad SQL como objetos de dominio

Question

Claramente, la separación de preocupaciones es un rasgo deseable en nuestro código y el primer paso obvio que la mayoría de la gente toma es separar el acceso a los datos de la presentación. En mi situación, LINQ To SQL se está utilizando en objetos de acceso a datos para el acceso a datos.

Mi pregunta es, ¿dónde debería detenerse el uso del objeto de la entidad? Para aclarar, podría pasar los objetos de la entidad hasta la capa de dominio, pero creo que un objeto de entidad es más que solo un objeto de datos, es como pasar un poco de DAL a la siguiente capa también.

Digamos que tengo una clase UserDAL, ¿debería exponer un objeto Usuario de la entidad al dominio cuando se llama a un método GetByID (), o debería escupir un objeto de datos simple puramente para almacenar los datos y nada más? (parece una duplicación derrochadora en este caso)

¿Qué han hecho ustedes en esta misma situación? ¿Hay un método alternativo para esto?

Espero que no haya sido demasiado vago.

Muchas gracias,

Martín.

Answer 1

Devuelvo IQueryable de POCO de mi DAL (que usa LINQ2SQL), por lo que ningún objeto de entidad Linq abandona el DAL. Estas POCO se devuelven a las capas de servicio y UI, y también se utilizan para pasar datos nuevamente a DAL para su procesamiento. Linq maneja esto muy bien:

 IQueryable<MyObjects.Product> products = from p in linqDataContext.Products 
                                          select new MyObjects.Product //POCO
                                          {
                                              ProductID = p.ProductID
                                          };
 return products;

Answer 2

Personalmente, no me gusta que mis entidades se extiendan a través de las capas. Mi DAL devuelve POCO (por supuesto, a menudo significa trabajo adicional, pero me pareció mucho más limpio, tal vez esto sea más simple en la próxima versión de .NET ;-)).

La pregunta no es tan simple y hay muchas ideas diferentes sobre el tema (me sigo haciendo la misma pregunta que tú).

Tal vez podría echarle un vistazo a la aplicación de muestra MVC Storefront : me gusta la esencia del concepto (la asignación que ocurre especialmente en la capa de datos).

Espero que esto ayude.

Answer 3

De hecho, he luchado con esto también. Utilizando LINQ vainilla simple a SQL, abandoné rápidamente las herramientas DBML, porque unía las entidades estrechamente con el DAL. Estaba luchando por un mayor nivel de ignorancia de persistencia, aunque Microsoft no lo hizo muy fácil.

Lo que terminé haciendo fue escribir a mano la capa de ignorancia de persistencia, al heredar el DAL de mis POCO. Los objetos heredados expusieron las mismas propiedades del POCO del que está heredando, por lo que mientras estaba dentro de la capa de ignorancia de persistencia, podría usar atributos para mapear los objetos. El llamado entonces podría convertir el objeto heredado a su tipo base, o hacer que el DAL haga eso por ellos. Preferí el último caso, porque disminuyó la cantidad de fundición que se necesitaba hacer. Por supuesto, esta fue una implementación principalmente de solo lectura, por lo que tendría que volver a visitarla para escenarios de actualización más complejos.

La cantidad de codificación manual para esto es bastante grande, porque también tengo que mantener manualmente (después de la codificación, para empezar) el contexto y el proveedor para cada fuente de datos, además de la herencia de objetos y las asignaciones. Si este proyecto estuviera en desuso, definitivamente pasaría a una solución más sólida.

De cara al Marco de la Entidad, la ignorancia de persistencia es una característica comúnmente solicitada de acuerdo con los blogs de diseño para el equipo de EF. Mientras tanto, si decides ir a la ruta EF, siempre puedes mirar una herramienta de ignorancia de persistencia preprogramada , como el proyecto EFPocoAdapter en MSDN, para ayudar.

Answer 4

Para la mayoría de los proyectos, usamos entidades LINQ to SQL como nuestros objetos comerciales.

El diseñador LINQ to SQL le permite controlar la accesibilidad de las clases y propiedades que genera, por lo que puede restringir el acceso a cualquier cosa que le permita al consumidor infringir las reglas comerciales y proporcionar alternativas públicas adecuadas (que respeten las reglas comerciales) en clases parciales

Incluso hay un artículo sobre cómo implementar su lógica comercial de esta manera en MSDN.

Esto le ahorra escribir un código repetitivo tedioso e incluso puede hacer que sus entidades sean serializables si desea devolverlas desde un servicio web.

Si usted crea o no una capa separada para la lógica de negocio realmente depende del tamaño de su proyecto (en general, los proyectos más grandes tienen una mayor variación entre la lógica comercial y las capas de acceso a datos).

Creo que LINQ to Entities intenta proporcionar una solución integral a este enigma al mantener dos modelos separados (un esquema conceptual para su lógica comercial y un esquema de almacenamiento para su acceso a los datos).

Answer 5

Tenga en cuenta que Linq to SQL no es una tecnología con visión de futuro. Fue lanzado, es divertido jugar con él, pero Microsoft no lo lleva a ninguna parte. Tengo la sensación de que tampoco será respaldado para siempre. Eche un vistazo al Entity Framework (EF) de Microsoft que incorpora parte de la bondad de Linq a SQL.

Answer 6

Utilizo un generador LinqToSQL personalizado, basado en uno que encontré en Internet, en lugar del MSLinqToSQLGenerator predeterminado. Para hacer que mis capas superiores sean independientes de tales objetos Linq, creo interfaces para representar cada una de ellas y luego uso tales interfaces en estas capas. Ejemplo:

public interface IConcept {
    long Code { get; set; }
    string Name { get; set; }
    bool IsDefault { get; set; }
}

public partial class Concept : IConcept { }

[Table(Name="dbo.Concepts")]
public partial class Concept
{
    private long _Code;
    private string _Name;
    private bool _IsDefault;
    partial void OnCreated();
    public Concept() { OnCreated(); }
    [Column(Storage="_Code", DbType="BigInt NOT NULL IDENTITY", IsPrimaryKey=true)]
    public long Code
    {
             //***
    }
    [Column(Storage="_Name", DbType="VarChar(50) NOT NULL")]
    public string Name
    {
             //***
    }
    [Column(Storage="_IsDefault", DbType="Bit NOT NULL")]
    public bool IsDefault
    {
             //***
    }
}

Por supuesto, hay mucho más que esto, pero esa es la idea.

Answer 7

Aquí hay una publicación similar, sin embargo, veo que su pregunta es más acerca de lo que debe hacer, en lugar de cómo debe hacerlo.

En aplicaciones pequeñas encuentro que una segunda implementación de POCO es un desperdicio, en aplicaciones más grandes (particularmente aquellas que implementan servicios web) el objeto POCO (generalmente un Objeto de Transferencia de Datos) es útil.

Si su aplicación cae en el caso posterior, es posible que desee consultar ADO.Net Data Services .

¡Espero que ayude!