É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
-
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.
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.