Où ajouter des fonctionnalités supplémentaires pour la couche de base de données (Linq-to-SQL)

Question

Quelle serait la meilleure méthode pour implémenter des fonctionnalités supplémentaires dans une couche de base de données utilisant Linq-to-SQL? Actuellement, je cherche à mettre en œuvre des fonctions pour ajouter des informations basées sur des préréglages et des tâches similaires?

Les insertions, mises à jour et suppressions nécessitent l'accès au DataContext et dans les classes Table vous n'avez pas accès au contexte. J'ai vu des solutions qui utilisent Singletons mais cela semble être un hack et je me demande si quelqu'un d'autre a rencontré ce problème et quelles étaient vos solutions? Existe-t-il une meilleure façon de mettre en œuvre des fonctionnalités similaires? La raison pour laquelle je cherche à ajouter cette fonctionnalité à la couche de base de données est que j'ai plusieurs applications qui utilisent toutes les mêmes objets de base de données et que je veux pouvoir utiliser ces fonctions depuis toutes les applications, donc je n'ai pas besoin de réécrire beaucoup de code.

---

Ce n'est pas tout à fait ce que je voulais dire. Je veux être capable de faire des actions complexes comme la mise à jour d'une table et l'ajout d'un enregistrement à une autre table en fonction des informations du premier. Supposons que j'ai sélectionné un enregistrement client et que je souhaite le mettre à jour avec des informations. Dans ce cas, je souhaite ajouter un autre enregistrement au tableau "Mises à jour" pour savoir quand les mises à jour ont eu lieu et qui les a effectuées. Ce n'est qu'un exemple bien sûr. Les choses à faire peuvent être plus complexes.

Fondamentalement je veux ajouter une méthode à un objet de table pour effectuer des modifications à une rangée spécifique dans cette table et puis faire des insertions et des mises à jour sur d'autres objets. Je sais que vous pouvez utiliser des cours partiels et je le fais déjà beaucoup.

Exemple:

db.Customers.Where(c => c.CustomerID == 5).AddOrder(orderDetails); 

Je sens que je ne peux pas vraiment mettre mon problème en mots pour le rendre compréhensible :)

Answer 1

Je déteste le dire, mais ce que sur les procédures stockées?

Sur mon projet, quelle que soit la fonctionnalité supplémentaire que nous voulons fournir, nous nous en tenons à une classe partielle. La classe de contexte de données est marquée partielle, vous pouvez donc ajouter des méthodes au contexte sans vous soucier de générer de nouveau le contexte nuking votre travail.

Answer 2

Vous pouvez utiliser des extensions de contexte de données génériques pour les méthodes d'accès aux données courantes telles que l'insertion, la suppression, etc., comme décrit dans http://weblogs.asp.net/stephenwalther/archive/2008/08/26/asp-net-mvc-tip-38-simplify-linq-to-sql-with-extension-methods.aspx. et des classes partielles pour des fonctionnalités moins communes comme le suggère Will.

Answer 3

Les classes d'entités dans Linq to SQL sont partielles. Vous pouvez les étendre avec les règles dont vous avez besoin.

Ou vous pouvez créer vos propres entités commerciales à partir des entités Linq vers SQL. Vos entités commerciales contiendraient alors les règles sur quand faire quoi.

Answer 4

Si vous êtes uniquement après l'ajout d'une fonctionnalité de wrapper autour LINQ ou une classe généralement, pourriez-vous pas utiliser l'approche de la méthode d'extension en C# 3 et au-dessus en utilisant des méthodes d'aide statiques le long de ces lignes:

public static class StringExtensions 
{ 
    public static int ToInt(this string oString) 
    { 
     return int.Parse(oString); 
    } 
} 

De cette façon, vous pourriez avoir une classe d'aide statique offrant une fonctionnalité d'assistance spécifique à des classes particulières, que vous pouvez porter entre deux projets ou éventuellement insérer dans une DLL séparée et simplement importer si nécessaire.