Comment suivre les modifications apportées aux objets métier?

Question

J'ai l'idée de créer un objet métier ou une entité pour représenter quelque chose comme une personne. Je peux ensuite sérialiser la personne en utilisant un DTO et l'envoyer au client. Si le client change l'objet, il peut avoir un drapeau IsDirty là-bas, donc quand il est renvoyé au serveur, je sais le mettre à jour.

Mais que se passe-t-il si j'ai un objet Order? Ceci a l'en-tête principal informaton, le client, le fournisseur, la date exigée, etc. Ensuite il a OrderItems qui est une liste < OrderItem>, étant les articles à commander. Je veux être en mesure d'utiliser cet objet métier sur mon interface utilisateur. J'ai donc des textboxes reliés à l'emplacement, au fournisseur, à la date requise, etc. et une grille connectée à OrderItems. Depuis OrderItems est une liste, je peux facilement ajouter et supprimer des enregistrements. Mais comment puis-je suivre cela, en particulier les éléments supprimés. Je ne veux pas que les éléments supprimés soient visibles dans ma grille et je ne devrais pas pouvoir les parcourir si j'utilise foreach, car ils ont été supprimés. Mais j'ai encore besoin de suivre le fait qu'il y avait une suppression. Comment puis-je suivre les modifications? Je pense que je dois utiliser une unité de travail? Mais alors le code semble devenir assez complexe. Alors je me demande pourquoi ne pas simplement utiliser DataTables et obtenir le suivi des modifications gratuitement? Mais ensuite j'ai lu comment les objets de travail sont la voie à suivre.

J'ai trouvé divers exemples sur des exemples de personnes simples, comme des commandes.

BTW utilisant C# 3.5 pour cela.

Answer 1

Les objets de données ne suivent pas les modifications. le suivi des modifications se produit sur le DataContext et les objets que vous avez récupérés via le DataContext. Ainsi, afin de suivre les changements que vous devez effectuer les opérations suivantes:

public class FooDataContext : DataContext 
{ 
    public Table<Order> Orders; 
} 

public class Order 
{ 
     [DbColumn(Identity = true)] 
     [Column(DbType = "Int NOT NULL IDENTITY", IsPrimaryKey = true, IsDbGenerated = true)] 
     public int Id { get; set; } 

     [DbColumn(Default = "(getutcdate())")] 
     [Column(DbType = "DateTime", CanBeNull = false, IsDbGenerated = true)] 
     public DateTime DateCreated { get; set; } 

     [Column(DbType = "varchar(50)", CanBeNull = false, IsDbGenerated = false)] 
     public string Name { get; set; } 
} 

Maintenant dans votre codebehind vous pouvez faire quelque chose comme:

public void UpdateOrder(int id, string name) 
{ 
    FooDataContext db = new FooDataContext(); 
    Order order = db.Orders.Where(o=>o.Id == id).FirstOrDefault(); 

    if (order == null) return; 

    order.Name = name; 

    db.SubmitChanges(); 
} 

Je recommande de ne pas utiliser directement le contexte de données dans le code derrière, mais c'est un bon moyen de commencer avec Linq To SQL. Je recommande de mettre toutes vos interactions de base de données dans un projet externe et appelez depuis l'interface graphique vers les classes qui encapsulent ce comportement.

Je vous recommande de créer un fichier Linq To Sql (dbml) si vous êtes nouveau dans Linq To Sql.

Cliquez avec le bouton droit sur votre projet dans l'explorateur de solution, puis sélectionnez Ajouter un nouvel élément. Sélectionnez le fichier Linq To SQL, et il vous permettra ensuite de vous connecter à votre base de données et de sélectionner les tables.

Vous pouvez ensuite regarder le code généré, et obtenir quelques bonnes idées sur la façon dont Linq To Sql fonctionne et ce que vous pouvez faire avec.

utiliser comme une ligne directrice sur le travail avec LINQ to SQL et qui vous mènera loin ...

Answer 2

Tout d'abord, vous pouvez utiliser un cadre existant qui aborde ces questions, comme CSLA.NET. L'auteur de ce cadre a abordé ces mêmes questions. Rendez-vous au http://www.rockfordlhotka.net/cslanet/ pour cela. Même si vous n'utilisez pas le framework complet, les concepts sont toujours applicables. Si vous vouliez rouler les vôtres, ce que j'ai fait par le passé était d'utiliser un type personnalisé dérivé de BindingList au lieu d'utiliser List pour mes collections. Inhereting de BindingList vous permet de remplacer le comportement d'ajouter/supprimer un élément. Ainsi, vous pouvez par exemple avoir une autre collection interne d'éléments "delteted". Chaque fois que la méthode Remove override est appelée sur votre collection, placez l'élément dans la collection "deleted", puis appelez l'implémentation de base de la méthode Remove. Vous pouvez faire la même chose pour les éléments ajoutés ou les éléments modifiés.

Answer 3

Vous avez besoin d'une unité de travail, mais n'en écrivez pas. Utilisez NHibernate ou un autre ORM. C'est pour ça qu'ils sont faits. Ils ont intégré l'unité de travail.

Les objets d'affaires sont en effet «la voie à suivre» pour la plupart des applications. Vous plongez dans une zone profonde et il y aura beaucoup d'apprentissage à faire. Regardez dans DDD.

Je vous déconseille fortement d'utiliser ce code dans votre code-behind. Regardez dans le modèle MVP.

Je voudrais aussi (pendant que je prenais la peine d'apprendre beaucoup de choses nouvelles, très critiques) regarder dans SOLID.

Vous voudrez peut-être jeter un coup d'œil au cours de JP Boodhoo, mais .net cours car il couvre beaucoup de ces choses.