Windows Form Controls et LINQ; Que dois-je retourner?

Question

Lorsque vous travaillez avec des contrôles de formulaire Windows et LINQ est-il une « meilleure option » pour la façon dont votre couche buisiness renvoie les données?

En ce moment je suis de retour DataTables afin que je puisse ensuite régler le DataSource au DataTable retourné. Y at-il une meilleure option? Pourquoi?

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>();
    }

---

Je trouve cette question similaire -> séparation préoccupations LINQ to de SQL et DTO

Answer 1

Personnellement, je préfère les objets de transfert de données, mais DataSets travaille dans un pincement.

En fait, l'idée est que si vous travaillez avec des objets de transfert de données (qui n'a pas de logique, et représentent le modèle que vous cherchez à travailler avec le client), qui est une abstraction qui peut vivre indépendamment des changements sur l'extrémité avant ou arrière. Il est généralement une bonne idée.

DataSets sont utiles, mais leur manque de sécurité de compilation (pas dans le cas de séries de données fortement typées cependant) en raison de l'accès de champ numérique / base de chaînes peut poser un problème.

En règle générale, il y a aussi une grande quantité de frais généraux dans sérialisation DataSets sur un fil par rapport à un objet de transfert de données.

Answer 2

J'aime créer mes propres classes de modèle en raison de la surcharge de jeux de données. Si vous retournez un tableau d'objets (ou tout ce qui implémente l'interface IList) vous pouvez toujours définir que égale à la propriété DataSource de la plupart des éléments ASP.NET.

Answer 3

Je tiens personnellement à mettre mes DataSources lors de l'utilisation des liens vers List<YourObject>

Answer 4

Je préfère la Business Logic pour retourner une instance d'un objet, tels que la voiture, ICar Liste (voiture) Laissez le DAL remplir l'objet pour vous. De cette façon, vous maintenez une séparation claire entre les données et l'interface utilisateur.

Answer 5

J'aime utiliser DataReaders plutôt que des ensembles de données, et je vais utiliser un bloc itérateur dans la couche de données pour mettre le datareader dans un IEnumerable<IDataRecord>. A partir de là, j'ai une sorte de l'étape supplémentaire entre la couche métier et les données à traduire IEnumerable dans un IEnumerable<MyBusinessObject>. Vous devriez être en mesure de transmettre ce message à la couche de présentation pour databinding ainsi.

J'aime cette approche parce qu'elle fait un meilleur travail de séparation des couches de données et d'affaires: la couche d'affaires devrait pas penser en termes de jeux de données, et la couche de données ne doit pas besoin de savoir comment construire des objets métier. Si je pense à cela comme un niveau distinct obtenir le meilleur des deux mondes. Un changement aux niveaux soit les données ou d'affaires signifie que je dois seulement changer le code d'usine pour que les constructions mes objets métier.