Расширьте класс сущности LINQ методами конструктора и сделайте этот класс сущности наследуемым от его класса DataContext

Question

Можно ли расширить классы сущностей LINQ-to-SQL с помощью методов-конструкторов и таким же образом;сделать этот класс сущностей наследуемым от его класса контекста данных? - По сути, преобразовать класс сущностей в бизнес-объект.

Это шаблон, который я сейчас использую:

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

Обновить:

Обратите внимание, что у меня есть два метода-конструктора в моем User класс.Я бы хотел перенести их в User сущность-класс и расширить User класс сущности в его классе контекста данных, так что контекст данных доступен классу сущности при "новом запуске".

Надеюсь, в этом есть смысл.

Answer 1

Кажется, не имеет смысла делать сущность типом DataContext.Это не обязательно должен быть DataContext, чтобы считаться бизнес-объектом, и вам не обязательно создавать тип, содержащий исходную сущность.Возможно, было бы лучше просто расширить класс сущности и содержать ссылку на DataContext с использованием 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(); }
   }
}

Если вы просто хотите, чтобы имена свойств отличались от имен столбцов базы данных, сделайте это в файле сопоставления.

Answer 2

У Рика Страла есть несколько действительно хороших статей, в которых рассматривается то, что, я думаю, вы ищете.Ознакомьтесь с его списком Статьи Linq Здесь

Answer 3

Наследование сущности из контекста данных - плохая идея.Это два отдельных объекта, и они предназначены для работы именно таким образом.Выполнение этого вызовет всевозможные проблемы, и меньше всего проблем с попыткой отправить кучу связанных изменений одновременно - просмотр нескольких контекстов данных приведет к сбою, поскольку каждый пытается работать независимо.