Windows Form Controls y LINQ; ¿Qué debería volver?

Question

Cuando se trabaja con los controles de Windows Forms y LINQ es que hay una "mejor opción" para la forma en que su capa de Buisiness devuelve los datos?

En este momento estoy regresando tablas de datos para que pueda entonces establecer el origen de datos a la DataTable devuelto. ¿Hay alguna opción mejor? ¿Por qué?

public class BLLMatrix
{
    public static DataTable GetMaintItems(int iCat)
    {
        IQueryable<tblCaseNotesMaintItem> tItems = DALMatrix.GetCNTable();
        return
            (tItems.Where(item => item.CategoryID == iCat & item.IsActive).OrderBy(item => item.OrderID).Select(
                item => new { item.ItemID, item.ItemDescription })).CopyLinqToDataTable();
    }

internal static class DALMatrix
{
    internal static MatrixDataContext MatrixDataContext = new MatrixDataContext();

    internal static Table<tblCaseNotesMaintItem> GetCNTable()
    {
        return MatrixDataContext.GetTable<tblCaseNotesMaintItem>();
    }

---

He encontrado esta pregunta similar -> La separación de las preocupaciones con LINQ to SQL y de DTO

Answer 1

En lo personal, prefiero Data Transfer Objects, sino conjuntos de datos trabajo en caso de apuro.

Básicamente, la idea es que si se está trabajando con los datos de objetos de transferencia (que no tienen lógica, y representa el modelo que usted está buscando para trabajar con el cliente), es una abstracción que puede vivir en la independencia de los cambios en la parte delantera o trasera. Es generalmente una buena idea.

conjuntos de datos son útiles, pero su falta de seguridad en tiempo de compilación (no en el caso de conjuntos de datos de tipo fuerte, aunque) debido al acceso campo numérico / basado en cadena puede plantear un problema.

Típicamente, también hay una gran cantidad de sobrecarga en la serialización de conjuntos de datos sobre un alambre en comparación con un objeto de transferencia de datos.

Answer 2

Me gusta crear mis propias clases del modelo debido a la sobrecarga de los conjuntos de datos. Si devuelve un array de objetos (o cualquier cosa que implementa la interfaz IList) todavía se puede establecer que igual a la propiedad DataSource de la mayoría de los elementos de ASP.NET.

Answer 3

Personalmente, me gusta estar mis DataSources al utilizar enlaces a List<YourObject>

Answer 4

Yo prefiero la lógica de negocios para devolver una instancia de un objeto, tales como coches, ICAR o la lista (Car) Que el DAL rellenar el objeto para usted. De esta manera a mantener una clara separación entre los datos y la interfaz de usuario.

Answer 5

Me gusta usar DataReaders en lugar de conjuntos de datos, y voy a utilizar un bloque de iteración de la capa de datos para convertir el datareader en un IEnumerable<IDataRecord>. A partir de ahí, tengo una especie de paso adicional entre el negocio y la capa de datos de traducir esa IEnumerable en un IEnumerable<MyBusinessObject>. Usted debe ser capaz de pasar esto a la capa de enlace de datos para la presentación también.

Me gusta este enfoque, ya que hace un mejor trabajo de separar las capas de datos y de negocios: la capa de negocio no debe pensar en términos de conjuntos de datos, y la capa de datos no debería necesitar saber cómo construir objetos de negocio. Si pienso en esto como un nivel separado consigo lo mejor de ambos mundos. Un cambio a cualquiera de los niveles de los datos o de negocios significa que sólo se necesita cambiar el código de fábrica para que las construcciones mis objetos de negocio.