Windows Form Controls e LINQ; O que devo voltar?

Question

Ao trabalhar com controles de formulário do Windows e LINQ há uma "melhor opção" para saber como sua camada de Buisiness retorna os dados?

Agora eu estou voltando DataTables para que eu possa, em seguida, definir a origem de dados para o DataTable retornado. Existe uma opção melhor? 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>();
    }

---

Eu encontrei esta pergunta semelhante -> Separando preocupações com Linq To SQL e do DTO

Answer 1

Pessoalmente, eu prefiro de transferência de dados objetos, mas DataSets trabalhar em uma pitada.

Basicamente, a idéia é que se você estiver trabalhando com dados de transferência Objects (que não têm lógica, e representam o modelo que você está olhando para o trabalho com o cliente), que é uma abstração que pode viver independentemente de mudanças na parte frontal ou traseira. É geralmente uma boa idéia.

DataSets são úteis, mas sua falta de segurança em tempo de compilação (não no caso de conjuntos de dados fortemente tipados embora) por causa de acesso numérica campo com base-string / pode representar um problema.

Normalmente, há também uma grande quantidade de sobrecarga em serialização conjuntos de dados ao longo de um fio comparado com um objecto de transferência de dados.

Answer 2

Eu gosto de criar minhas próprias classes de modelo por causa da sobrecarga de DataSets. Se você retornar uma matriz de objeto (ou qualquer coisa que implementa a interface IList), você ainda pode definir que igual a propriedade DataSource da maioria dos elementos do ASP.NET.

Answer 3

Eu pessoalmente gosto de definir meus DataSources ao usar links para List<YourObject>

Answer 4

Eu prefiro a lógica de negócios para retornar uma instância de um objeto, como carro, ICAR ou List (Car) Deixe o DAL preencher o objeto para você. Desta forma, você manter uma clara separação entre dados e interface do usuário.

Answer 5

Eu gosto de usar DataReaders ao invés de conjuntos de dados, e eu vou usar um bloco iterador na camada de dados para ligar o datareader em um IEnumerable<IDataRecord>. De lá, eu tenho uma espécie de passo extra entre o negócio ea camada de dados para traduzir isso IEnumerable em um IEnumerable<MyBusinessObject>. Você deve ser capaz de passar isso para a camada de apresentação para a ligação de dados também.

Eu gosto desta abordagem, porque ele faz um trabalho melhor separar as camadas de dados e de negócios: a camada de negócios não deve pensar em termos de conjuntos de dados, e a camada de dados não deve precisa saber como construir objetos de negócios. Se eu pensar nisso como uma camada separada I obter o melhor dos dois mundos. A alteração dos tanto os meios de dados ou de negócios Tiers eu só preciso alterar o código de fábrica para que constrói meus objetos de negócios.