views:

164

answers:

1

I'm looking at implementing some LINQ to SQL but am struggling to see how we woudl add in access control business rules such as customer a can only view their orders. In ado.net data services, query intercptors do exactly what I am after, and can see how to check on update / insert / delete, but is there an equivalent of this:

[QueryInterceptor("Orders")] 
public IQueryable<Orders> OnQueryOrders(IQueryable<Orders> orderQuery) 
{ 

      return from o in orderQuery 
         where o.Customers.ContactName == HttpContext.Current.User.Identity.Name 
         select o; 
}

Or wil I need to control via accessors along the line of: GetOrdersByCustomer(string customerId)

A: 

I think, in this case, the better solution would be to build a true Business Layer that sits between the Application Layer and your LINQ to SQL classes.

You would then query your Business Layer, which in turn would implement all your Business Logic and filtering. If architected properly, that Business Layer could be fairly transparent to anybody coding the Application Layer and then everybody would be happy.

Justin Niessner
Hi JustinYes, that is looking like the route I will have to take.My approach looks like it will be:make my dataContext sealed, but my data objects public (ie tables in linq to sql) Expose methods out from BL which can take in predicate functions which will then get added to an expression tree with business security logic. In my prototypes this is working and while a little confusing initially, what is exposed is pretty clear but flexible.