Extend linq-to-sql partial class to avoid writing a property?

Question

I have a linq-to-sql class. I have a property "Password" for which I want to call the underlying ASP.NET Membership provider. Thus, I do not want this property written out directly but via my own code. I basically want to create a facade/proxy for this property such that I may use the underlying membership provider or a custom stored procedure.

I want to accomplish without modifying the LINQ-TO-SQL designer generated code, if at all possible.

Curtis - your question, as is, makes little sense. ASP.Net membership does not 'underlie' Linq2Sql. You will get better results if you describe what you are trying to do using simple terms that everyone can understand. Mis-using terms of art/buzzwords does not help. Edit your question and let us take another look at it. — Sky Sanders, Apr 08 '10 at 08:45
It does make sense for anyone who knows both the ASP.NET Membership API and how LINQ-to-SQL works. However, for those who may prefer a more generic description. I want to make a linq-to-sql property such that it is not written to the database by the generated code/datacontext but instead is written to the database by a custom, user defined method, and, ideally, I want to do this without making any changes to the designer generated class including but not limited to changing meta-data, removing the property outright, or any other changes. I think my own solution satisfies this best. — Curtis White, Apr 08 '10 at 13:56
A couple points: When replying to someone in comments, you should use the '@' symbol and part of their name to make sure that they get the message. e.g. '@Sky - It does...'. Second: I feel I have a fairly firm understanding of both the membership API (see my answers) and L2S and your question, as presented, is not clear in it's desired result. This can be evidenced by the dearth of applicable responses. You may find that when asking for help a more conciliatory attitude will net better results. — Sky Sanders, Apr 11 '10 at 10:25

PanJanek · Answer 1 · 2010-04-08T15:13:47.050

3

It is possible. You can add your properties and methods to linq generated class using partial class mechanism. Linq generated classes are marked partial so you can add class members with:

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
     {
         // ...
     }
  }
}

You have to place the partial class in the same namespace as the rest of dbml.

edited Apr 08 '10 at 15:13

answered Apr 07 '10 at 20:59

PanJanek

6,593
2
34
41

Poor answer, it is very general and does not answer the specific question. – Curtis White Apr 08 '10 at 13:50
@Curtis: As far as I understood your question, you want to add some code (property) to linq-generated class, and that is what I've explained how to do. I don't know the exact logic of password retrieving you use. I answered how to add proxy property to linq classes (I added some more code while ago to make it more understandable). – PanJanek Apr 08 '10 at 15:18
Yes, I understand how to do that. This question deals with how to modify a designer generated property, i.e a property that is generated already. As my own answer already stated, there are partial methods for this for each property. But, my problem goes beyond that in that I do not want the property persisted using the LINQ framework but do not want to modify the designer generated code either. Not touching the designer generated code is key because once we go that route then it changes the whole work flow. – Curtis White Apr 08 '10 at 15:26
Good answers would be: throw an exception using partial property and add a custom method. Create a custom datacontext and check the change set (possibly). Or one might even mention a third party tool that allows designer generated changes to be saved, such as Huggati. Instead you presented a solution to the trivial case. – Curtis White Apr 08 '10 at 15:30

score 0 · Answer 2 · answered Jul 25 '11 at 11:12

The best option is to remove the property from the designer and write it in code, in the partial class, as described by PanJanek.

However, if you do it this way, you are pursuing a bad design. You're introducing a dependency into your entity class that breaks layer encapsulation. Entity classes shouldn't know about providers any more than they know about the DataContext that loads them. They aren't really meant to be anything more than containers for data going in and out of the database.

You should consider making a separate class that wraps the entity, the context, the username provider, and whatever other services you require, and in that class retrieve the username and do the required operations to your entity.

score -3 · Answer 3 · answered Apr 07 '10 at 20:59

It looks like it might be possible to create a custom DataContext to handle this situation.

http://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx

There are partial methods for the individual properties as, well and an OnValidate method.

In my case, I think the best solution is to throw an exception in the property changing method and add a public method for setting this individual property. This solution while not perfect will avoid touching the SQL generated code, where the property could be set to readonly or the setter removed.

Other suggestions welcome.

Extend linq-to-sql partial class to avoid writing a property?

3 Answers3