Extend a LINQ entity-class with constructor methods and make that entity-class inherit from it's DataContext class

Question

Is it possible to extend LINQ-to-SQL entity-classes with constructor-methods and in the same go; make that entity-class inherit from it's data-context class?--In essence converting the entity-class into a business object.

This is the pattern I am currently using:

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

Update:

Notice that I have two constructor-methods in my User class. I'd like to transfer those to the User entity-class and extend the User entity-class on it's data-context class, so that the data-context is available to the entity-class on "new-up".

Hope this makes sense.

Answer 1

It doesn't seem to make sense to make an entity a type of DataContext. It doesn't need to be a DataContext in order to be considered a business object, nor do you necessarily need to create a type that contains the original entity. It might be better to just extend the entity class and contain a reference to a DataContext using 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(); }
   }
}

If you just want the property names to be different than the database column names, do that in the mapping file.

Answer 2

Rick Strahl has a number of really good articles that address what I think you are looking for. Check out his list of Linq Articles Here

Answer 3

Inheriting an entity from a data context is a bad idea. They are two discrete objects and are designed to operate that way. Doing this will cause all sorts of issues least of all problems with trying to submit a bunch of related changes together at the same time - going through multiple data contexts will cause this to fail as each tries to work independently.