Estendi una classe di entità LINQ con metodi di costruzione e fai ereditare tale classe di entità dalla sua classe DataContext

Question

È possibile estendere le classi di entità LINQ-to-SQL con metodi di costruzione e allo stesso modo; far ereditare quella classe di entità dalla sua classe di contesto di dati? - In sostanza, convertire la classe di entità in un oggetto business.

Questo è lo schema che sto attualmente usando:

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);
        }
    }
}

Aggiornamento:

Nota che ho due metodi di costruzione nella mia classe User . Vorrei trasferirli nella classe di entità User e estendere la classe di entità User sulla sua classe di contesto di dati, in modo che il contesto dei dati è disponibile per la classe di entità su "new-up".

Spero che abbia senso.

Answer 1

Non ha senso trasformare un'entità in un tipo di DataContext. Non è necessario che sia un DataContext per essere considerato un oggetto business, né è necessario creare un tipo che contenga l'entità originale. Potrebbe essere meglio estendere la classe di entità e contenere un riferimento a un DataContext usando la composizione:

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(); }
   }
}

Se vuoi solo che i nomi delle proprietà siano diversi dai nomi delle colonne del database, fallo nel file di mappatura.

Answer 2

Rick Strahl ha un numero di articoli davvero validi che parlano di ciò che penso tu stia cercando. Consulta il suo elenco di Articoli Linq qui

Answer 3

Ereditare un'entità da un contesto di dati è una cattiva idea. Sono due oggetti discreti e sono progettati per funzionare in questo modo. In questo modo si causano tutti i tipi di problemi, meno di tutti i problemi relativi al tentativo di inviare contemporaneamente una serie di modifiche correlate: passare attraverso più contesti di dati provocherà il fallimento di ogni tentativo di funzionare in modo indipendente.