Étendre une classe d'entités LINQ avec des méthodes de constructeur et faire en sorte que cette classe d'entités hérite de sa classe DataContext

StackOverflow https://stackoverflow.com/questions/222897

  •  03-07-2019
  •  | 
  •  

Question

Est-il possible d'étendre les classes d'entités LINQ-to-SQL avec constructor-methods et dans le même chemin; faire en sorte que cette classe d'entité hérite de sa classe de contexte de données? - Convertir la classe d'entité en objet métier.

Voici le modèle que j'utilise actuellement:

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 méthodes de constructeur dans ma classe User . Je souhaite transférer ceux-ci vers la classe d'entité Utilisateur et pour étendre la classe d'entité Utilisateur sur sa classe de contexte de données, de sorte que le contexte de données est disponible pour la classe d'entités sur "new-up".

J'espère que cela a du sens.

Était-ce utile?

La solution

Cela ne semble pas logique de faire d’une entité un type de DataContext. Il n'est pas nécessaire que ce soit un DataContext pour être considéré comme un objet métier, pas plus qu'il n'est nécessaire de créer un type contenant l'entité d'origine. Il peut être préférable d’élargir la classe d’entités et de contenir une référence à un DataContext à l’aide de la composition:

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 souhaitez simplement que les noms de propriété soient différents des noms de colonne de la base de données, faites-le dans le fichier de mappage.

Autres conseils

Rick Strahl a rédigé de très bons articles qui répondent à ce que je pense que vous recherchez. Découvrez sa liste de Les articles de Linq ici

Hériter une entité d’un contexte de données est une mauvaise idée. Ce sont deux objets distincts et conçus pour fonctionner de cette façon. Cela posera toutes sortes de problèmes, mais le moindre problème pour ce qui est d'essayer de soumettre plusieurs modifications connexes en même temps - le fait de passer par plusieurs contextes de données entraînera un échec, chacun essayant de travailler de manière indépendante.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top