Etendre une classe d'entités LINQ avec des méthodes constructor et rendre cette classe d'entité héritée de sa classe DataContext

Question

Est-il possible d'étendre des classes d'entités LINQ-to-SQL avec des méthodes-constructeurs et dans le même but; rendre cette classe d'entité héritée de sa classe de contexte de données? - Essentiellement la conversion de la classe d'entité en un objet métier.

C'est le modèle que je suis actuellement en utilisant:

namespace Xxx 
{ 
    public class User : Xxx.DataContext 
    { 
     public enum SiteAccessRights 
     { 
      NotRegistered = 0, 
      Registered = 1, 
      Administrator = 3 
     } 

     private Xxx.Entities.User _user; 

     public Int32 ID 
     { 
      get 
      { 
       return this._user.UsersID; 
      } 
     } 

     public Xxx.User.SiteAccessRights AccessRights 
     { 
      get 
      { 
       return (Xxx.User.SiteAccessRights)this._user.UsersAccessRights; 
      } 

      set 
      { 
       this._user.UsersAccessRights = (Int32)value; 
      } 
     } 

     public String Alias 
     { 
      get 
      { 
       return this._user.UsersAlias; 
      } 

      set 
      { 
       this._user.UsersAlias = value; 
      } 
     } 


     public User(Int32 userID) 
     { 
      var user = (from u in base.Users 
         where u.UsersID == userID 
         select u).FirstOrDefault(); 

      if (user != null) 
      { 
       this._user = user; 
      } 
      else 
      { 
       this._user = new Xxx.Entities.User(); 

       base.Users.InsertOnSubmit(this._user); 
      } 
     } 


     public User(Xxx.User.SiteAccessRights accessRights, String alias) 
     { 
      var user = (from u in base.Users 
         where u.UsersAccessRights == (Int32)accessRights && u.UsersAlias == alias 
         select u).FirstOrDefault(); 

      if (user != null) 
      { 
       this._user = user; 
      } 
      else 
      { 
       this._user = new Xxx.Entities.User 
       { 
        UsersAccessRights = (Int32)accessRights, 
        UsersAlias = alias 
       }; 

       base.Users.InsertOnSubmit(this._user); 
      } 
     } 


     public void DeleteOnSubmit() 
     { 
      base.Users.DeleteOnSubmit(this._user); 
     } 
    } 
} 

Mise à jour:

Notez que j'ai deux constructeur-méthodes dans ma classe User. Je voudrais transférer ceux-ci à User entité-classe et étendre la classe d'entité User sur sa classe de contexte de données, de sorte que le contexte de données est disponible à la classe d'entité sur "new-up".

Espérons que cela a du sens.

Answer 1

Il ne semble pas logique de faire d'une entité un type de DataContext. Il n'a pas besoin d'être un DataContext pour être considéré comme un objet métier, et vous n'avez pas nécessairement besoin de créer un type qui contient l'entité d'origine. Il pourrait être préférable d'étendre simplement la classe d'entité et contiennent une référence à une composition en utilisant DataContext:

namespace Xxx.Entities 
{ 
    public partial class User : IDisposable 
    { DataContext ctx; 

    public static GetUserByID(int userID) 
     { var ctx = new DataContext(); 
     var user = ctx.Users.FirstOrDefault(u=>u.UsersID == userID); 

     if (user == null) 
      { 
      user = new User(); 
      ctx.Users.InsertOnSubmit(user); 
      } 

     user.ctx = ctx; 
     return user;   
     }  

    public void Dispose() { if (ctx != null) ctx.Dispose(); } 
    } 
} 

Si vous voulez juste les noms de propriétés soient différentes que les noms de colonnes de base de données, faire dans le fichier de mappage.

Answer 2

Rick Strahl a un certain nombre de très bons articles qui répondent à ce que je pense que vous cherchez. Consultez sa liste de Linq Articles Here

Answer 3

L'héritage d'une entité à partir d'un contexte de données est une mauvaise idée. Ils sont deux objets distincts et sont conçus pour fonctionner de cette façon. Cela entraînera toutes sortes de problèmes, notamment le fait d'essayer de soumettre ensemble un ensemble de modifications connexes. En passant par plusieurs contextes de données, cela échouera alors que chacun tentera de fonctionner indépendamment.