我有一个 linq-to-sql 类。我有一个属性“密码”,我想为其调用底层 ASP.NET 成员资格提供程序。因此,我不希望通过我自己的代码直接写出这个属性。我基本上想为这个属性创建一个外观/代理,这样我就可以使用底层的成员资格提供程序或自定义存储过程。
如果可能的话,我想在不修改 LINQ-TO-SQL 设计器生成的代码的情况下完成。
我有一个 linq-to-sql 类。我有一个属性“密码”,我想为其调用底层 ASP.NET 成员资格提供程序。因此,我不希望通过我自己的代码直接写出这个属性。我基本上想为这个属性创建一个外观/代理,这样我就可以使用底层的成员资格提供程序或自定义存储过程。
如果可能的话,我想在不修改 LINQ-TO-SQL 设计器生成的代码的情况下完成。
有可能的。您可以使用部分类机制将属性和方法添加到 linq 生成的类。Linq 生成的类被标记为部分,因此您可以添加类成员:
public partial class YourLinqClass
{
// your methods and properties. refer linq properites and methods with "this."
// example:
public string Password
{
get
{
int id = this.UserId;
string password = // ... get password
return password;
}
set
{
// ...
}
}
}
您必须将部分类放在与 dbml 的其余部分相同的命名空间中。
最好的选择是从设计器中删除该属性并将其写入部分类中的代码中,如 PanJanek 所述。
但是,如果你这样做,你就是在追求一个糟糕的设计。您在实体类中引入了一个破坏层封装的依赖项。实体类对提供者的了解不应该比它们对加载它们的 DataContext 的了解更多。它们实际上并不仅仅是用于进出数据库的数据的容器。
您应该考虑创建一个单独的类来包装实体、上下文、用户名提供程序以及您需要的任何其他服务,并在该类中检索用户名并对您的实体执行所需的操作。
看起来可以创建一个自定义 DataContext 来处理这种情况。
http://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx
个别属性也有部分方法,还有 OnValidate 方法。
就我而言,我认为最好的解决方案是在属性更改方法中抛出异常并添加一个公共方法来设置这个单独的属性。这个解决方案虽然不完美,但会避免接触 SQL 生成的代码,其中属性可以设置为只读或删除 setter。
欢迎提出其他建议。