Asesoramiento sobre LINQ al diseño de objetos correlación de SQL

Question

Espero que el título y el siguiente texto son claros, no estoy muy familiarizado con los términos correctos así que por favor me corrija si me da nada mal. Estoy usando LINQ ORM por primera vez y me pregunto cómo abordar la siguiente.

Decir que tengo dos tablas de BD:

User
----
Id
Name


Phone
-----
Id
UserId
Model

El generador de código de LINQ produce un montón de clases de entidad.

A continuación, escribir mis propias clases e interfaces que envuelven estas clases Linq:

class DatabaseUser : IUser
{
    public DatabaseUser(User user)
    {
        _user = user;
    }

    public Guid Id 
    {
        get { return _user.Id; } 
    }

    ... etc
}

hasta ahora tan bueno.

Ahora es bastante fácil de encontrar un usuarios de teléfonos de Phones.Where(p => p.User = user) pero seguramente comsumers de la API no debe necesidad de escribir sus propias consultas LINQ para llegar a los datos, por lo que debe envolver esta consulta en una función o propiedad alguna parte.

Así que la pregunta es, en este ejemplo, ¿le añade una propiedad Móviles a IUser o no?

En otras palabras, debe ser específicamente mi interfaz modelar mis objetos de bases de datos (en cuyo caso no pertenece Móviles en IUser), o son en realidad simplemente proporcionar un conjunto de funciones y propiedades que son conceptualmente asociada a un usuario (en cuyo caso se hace)?

Parece inconvenientes de ambos puntos de vista, pero me pregunto si hay un método estándar para el problema. O simplemente cualquier palabra generales de la sabiduría que podrían compartir.

Lo primero que pensé fue utilizar métodos de extensión, pero en realidad eso no funciona en este caso.

Answer 1

He tenido algunas experiencias terribles que tratan de entidades abstractas LinqToSql detrás de interfaces. Fue hace un tiempo, pero a partir de la memoria el problema principal era que se rompe totalmente asociaciones. Por ejemplo, si tiene un Customer -> relación Order, que terminan exponiéndolo como un ICustomer, con una colección de IOrders, lo que significa que Customer tiene que hacer mapeo incómoda para lanzar su colección interna de los objetos Order como IOrders <. / p>

A continuación, hay que asumir que cuando un IOrder se pasa de nuevo, que podemos echarlo a un Order. De lo contrario LinqToSql no puede tratar con él, pero después de que se pierde el punto de tener la interfaz de allí en primer lugar.

No te recomiendo que no intente y abstraer las clases de entidad demasiado, LinqToSql en realidad no pone ningún tipo de magia real en ellos, el DataContext se encarga de su ciclo de vida persistencia, por lo que permanecen comprobable.

Los aspectos que estaría buscando ocultar detrás de una interfaz serían las interacciones con DataContext, por ejemplo, el uso de clases de estilo Repositorio:

public interface IPhoneRepository 
{
    IEnumerable<Phone> GetPhonesForUser(User user);
}

public class L2SPhoneRepository : IPhoneRepository
{
    private readonly MyDataContext context;

    public L2SPhoneRepository(MyDataContext context)
    {
        this.context = context;
    }

    public IEnumerable<Phone> GetPhonesForUser(User user)
    {
        return context.Phones.Where(p => p.User == user);
    }
}

Answer 2

Su interfaz debe modelar cómo le gustaría que para los objetos que se utilizarán. Puesto que usted está tratando de abstraer, entonces el consumidor no debe tener que consultar la base de datos. Si usted hace que una propiedad, o una llamada a una función separada (es decir, GetPhones ()), es totalmente de usted. Puesto que usted está envolviendo completamente las cosas, tendrá que tomar algunas decisiones acerca de qué tan profundo / perezosamente desea cargar sus objetos.

Answer 3

Se deben agregar las propiedades celulares a IUser y que sea anulable, por lo que para un usuario que no tienen teléfono, será nula.

Dado que no desea que los consumidores de la API para escribir consultas, que debiera implementar funciones como GetUser () .. etc.

Aquí está una buena lista de la aplicación del artículo ABT n niveles en Asp.net

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416

Answer 4

tiendo a considerar la Linq2Sql cosas relacionadas a ser un detalle de implementación del código de acceso de datos y, al igual que la estructura real de la base de datos, no necesariamente debe ser expuesto a otras partes del sistema.

Si su API va a ser consumidos por otras personas que debe ser coherente y fácil de usar y carece por lo que el consumidor no necesita conocer. Si estoy tratando con los usuarios y sus teléfonos Realmente no quiero saber sobre DataContexts o (ugh) de datos.

Además, al mantener la mayor parte de su código ignorantes de las L2S y la base de datos tendrá una prueba más fácil, realizar cambios de esquema (oh, por lo que ahora la tabla usuario necesita para mantener un historial de todos los cambios realizados) o incluso cambiar el ORM completamente.