¿Cuáles son sus formas favoritas de encapsular LINQ en clases de entidad de SQL y clases de contexto de datos en objetos de negocios?Entidad de LINQ a SQL y clases de contexto de datos: encapsulación de objeto de negocio
¿Qué ha encontrado que funciona en una situación dada?
¿Has inventado o adoptado patrones específicos?
He encontrado un patrón que creo que funciona mejor - En mi caso, al menos.
Extiendo clases de entidades usando clases parciales. Utilizo clases parciales para que la firma de la entidad no cambie (consulte la llamada DeleteOnSubmit en el método Delete).
He preparado un pequeño ejemplo.Aquí está una imagen de la base de datos y LINQ para configurar la clase de SQL:
Y aquí está la clase parcial en el que pongo en práctica la lógica de negocio:
/// <summary>
/// This class extends BusinessLogicDataContext.Products entity class
/// </summary>
public partial class Product
{
/// <summary>
/// New up a product by column: dbo.Products.ProductId in database
/// </summary>
public Product(Int32 id)
{
var dc = new BusinessLogicDataContext();
// query database for the product
var query = (
from p in dc.Products
where p.ProductId == id
select p
).FirstOrDefault();
// if database-entry does not exist in database, exit
if (query == null) return;
/* if product exists, populate self (this._ProductId and
this._ProductName are both auto-generated private
variables of the entity class which corresponds to the
auto-generated public properties: ProductId and ProductName) */
this._ProductId = query.ProductId;
this._ProductName = query.ProductName;
}
/// <summary>
/// Delete product
/// </summary>
public void Delete()
{
// if self is not poulated, exit
if (this._ProductId == 0) return;
var dc = new BusinessLogicDataContext();
// delete entry in database
dc.Products.DeleteOnSubmit(this);
dc.SubmitChanges();
// reset self (you could implement IDisposable here)
this._ProductId = 0;
this._ProductName = "";
}
}
Usando la lógica de negocio en marcha:
// new up a product
var p = new Product(1); // p.ProductId: 1, p.ProductName: "A car"
// delete the product
p.Delete(); // p.ProductId: 0, p.ProductName: ""
Además: las clases de entidad LINQ a SQL son de naturaleza muy abierta. Esto significa que la propiedad correspondiente a la columna dbo.Products.ProductId implementa tanto un getter como un setter; este campo no debe ser modificable.
Que yo sepa, no se puede anular el inmueble con las clases parciales, por lo que lo que suelo hacer es implementar un administrador que se estrecha el objeto con una interfaz:
public interface IProduct
{
Int32 ProductId { get; }
void Delete();
}
En este momento estoy tratando de usar las clases de entidad LINQ a SQL como objetos de negocios, para pasarlos de una función a otra y a un servicio.
Por supuesto, debe tener clases de entidad separadas para el acceso a la base de datos, por lo que el diseño de su base de datos puede cambiar sin cambiar los objetos comerciales.
¡Estaría muy interesado en una buena solución para esto también!
Hice algunos experimentos utilizando Entity Framework y Linq to Entities como una forma de separar más mi código de cliente de la base de datos, pero me pareció difícil de usar y estaba preocupado por el rendimiento.
En mi proyecto actual utilizo Linq a SQL como mi capa de datos, pero tengo clases separadas donde implemento todas las consultas de Linq. Las clases devuelven entidades definidas en mi contexto de Linq a SQL, pero las consultas están ocultas en los métodos.
Salida del código fuente de la aplicación de ejemplo MVC que Rob Connery está armando:
http://www.codeplex.com/mvcsamples/
Él tiene una capa de entidad separada que se asigna a la LINQ a clases de SQL.
Tiendo a utilizar el patrón Repositorio para encapsular DataContexts.
Me gustaría encontrar una mejor manera de emitir objetos POCO de mi capa de datos durante el uso de LINQ2SQL sin embargo.
Encontré los artículos por Ian Cooper on CodeBetter.com y Stephen Walther serie de gran valor para comprender la necesidad de escribir las entidades POCO primero y luego asignarlas a la base de datos en lugar de hacerlo al revés (que es lo que solía hacer siempre).
Estoy jugando con la idea de tener una capa separada de modelo OO (mejor soporte para las prácticas OO), pero que usan LINQ to SQL bajo el capó. La idea es tener un archivo xml que una herramienta personalizada usará para generar el código. Dado que las entidades de LINQ to SQL están demasiado saturadas para mis preferencias, generaré automáticamente nuevas clases para usar como mis entidades y, por supuesto, DataContext estará completamente oculto para el código del cliente. La respuesta abreviada es: Crear nuevas clases de entidad pero usar las entidades subyacentes LINQ to SQL y DataContext.
Acabo de publicar una muestra de cómo se puede estructure su aplicación que usa Linq a Sql para el almacenamiento, usando plantillas IoC y T4.
http://daniel.wertheim.se/2010/03/14/linq-to-sql-how-to-separate-the-entities-and-the-datacontext/
Establecer en la comunidad wiki. – roosteronacid