Encapsulation and LINQ to SQL

re: Encapsulation and LINQ to SQL

jdavidroberts — Fri, 25 Jan 2008 01:11:05 GMT

I really like this approach, but unless I'm missing something, there is a hole in the case of FK relationships. I'm thinking of a case where there is a one-to-many between another entity and Customers. i.e., if a query like the one below is used:

from sp in db.SalesPeople

from cust in sp.Customers

...

Maybe I'm missing something, but I'd be interested in your thoughts on the right way to filter Customers "behind the scenes" in this case.

re: Encapsulation and LINQ to SQL

kfarmer@microsoft.com — Fri, 25 Jan 2008 01:21:30 GMT

I haven't played around with this in a while. Perhaps instead of a bare EntitySet you could expose a property that returned a filtererd set. The problem I could see would be one of composability -- I'm not sure what sort of expression tree LINQ to SQL would be handed in that case.

You can also look into DataShape, and how that could be used to preload related items.

re: Encapsulation and LINQ to SQL

Quango — Sun, 16 Mar 2008 13:45:41 GMT

Thanks for a very useful article. I'm stuck on one point where I need a more generic query - how can I create my query predicate in a generic way. e.g. my function

GetEqualQuery(Type entityType, string propName, object value)

{

}

needs to return Expression<Func<TEntity,bool>>

I have managed to create simple Expression.Equals() expressions but cannot figure out how to create this particular type!

tia dev @ conficient . com

WARNING WARNING !!

Quango — Fri, 20 Jun 2008 11:22:24 GMT

Be VERY careful using this approach.

I've just found after two months work that LinqDataSource won't let you use the "secure" datacontext for update/insert/delete - because the table properties, e.g. Customers do not return Table<T>, and that is the ONLY type that LINQdatasource will deign to work with. Hence I am trying to figure out a workaround for this but at present it's a major issue.