Visual Studio écrasant sur Linq stocké procédures

Question

J'ai plusieurs procédures stockées qui renvoient un jeu de résultats fortement typé. J'ai appris que Linq a sa propre méthode pour gérer cela, qui doit être écrasée (ou du moins, il semble que ce soit le cas).

Mon problème est Visual Studio insiste sur la recréation forcée des procédures stockées parfois. Je veux désactiver cela.

Voici mon fichier modifié manuellement:

[Function(Name="dbo.spGetNote")] 
    public ISingleResult<Note> spGetNote([Parameter(DbType="Int")] System.Nullable<int> noteId, [Parameter(DbType="Int")] System.Nullable<int> securityUserId) 
    { 
     IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), noteId, securityUserId); 
     return ((ISingleResult<Note>)(result.ReturnValue)); 
    } 

Voici ce qu'il à sa valeur par défaut:

[Function(Name="dbo.spGetNote")] 
    public ISingleResult<spGetNoteResult> spGetNote([Parameter(DbType="Int")] System.Nullable<int> noteId, [Parameter(DbType="Int")] System.Nullable<int> securityUserId) 
    { 
     IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), noteId, securityUserId); 
     return ((ISingleResult<spGetNoteResult>)(result.ReturnValue)); 
    } 

Ceci est l'un des plus petits.

Il y a d'autres domaines qui dérangent, mais ceux-ci sont réparables. Il obtient réel vieux en remontant et en ajustant cela. Ce que nous avons fini par faire, c'est que chaque procédure stockée qui renvoie son propre élément fortement typé reçoit son propre contexte/classe de données afin que chaque fois que nous mettons à jour notre DAL, il (Visual Studio) ne piétine pas notre changements personnalisés.

Y at-il quelque chose que je peux faire pour aider à soulager ce mal de tête? Ce qui a amené tout cela, c'est que je nettoie les espaces de nom et que j'ai trouvé que je ne peux pas changer l'espace de noms sans que Visual Studio n'écarte chaque procédure stockée dans le projet et je ne veux pas passer des heures nettoyer ce gâchis. Apparemment, un remplacement global n'est pas suffisant, car Visual Studio détecte cela et dit ensuite qu'il ne peut pas trouver une chaîne de connexion et doit reconstruire chaque fichier impliqué.

Answer 1

Depuis l'auto-généré DataContext est partielle, vous pouvez créer votre propre partiel classe et déplacez vos méthodes/types personnalisés dans le partiel. à savoir

MyDataContext.cs

public partial MyDataContext 
{ 
     [Function(Name="dbo.spGetNote")]   
     public ISingleResult<Note> spGetNote([Parameter(DbType="Int")]... 
} 

public class Note... 

Joe

Answer 2

Ne pas modifier le code généré. Si vous le faites, chaque fois que vous regardez le fichier dbml, vos modifications risquent d'être perdues. Vous pourrait (je n'ai pas essayé) être en mesure de résoudre ce problème en éditant le dbml à la main (c'est juste xml); mais l'OMI, la façon la plus simple de gérer c'est à l'intérieur de votre référentiel, de faire une projection du type généré dbml à votre type:

Note[] SomeFunc(...) { 
    using(var ctx = ...) { 
     return (from row in ctx.SomeSP(...) // row is the dbml type 
      select new Note { // Note is our custom type 
       Id = row.Id, 
       Name = row.Name, 
       // etc 
       }).ToArray(); // or whatever 
    } 
}