2009-09-18 4 views
0

SQL에 대한 일부 LINQ를 구현하려고하지만 고객 a와 같은 액세스 제어 비즈니스 규칙을 추가하는 방법에 대해 고심하고 있습니다. ado.net 데이터 서비스에서 , 쿼리 intercptors 정확히 내가 후에 오전 및 갱신/삽입/삭제를 확인하는 방법을 볼 수 있지만이이 동등한 무엇 않습니다linq to sql query interceptor

[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; 
} 

또는 줘야 내가 필요 GetOrdersByCustomer (string customerId)

+0

개인적으로 GetOrdersByCustomer와 같은 것을 훨씬 쉽게 이해하고 유지할 수 있습니다. 인터셉터는 여기서 불필요한 복잡성을 느끼고 있습니다. 자신의 코드를 유지해야 할 사람과 자신만큼 영리하지 않은 사람을 생각해보십시오. –

+0

단순한 시나리오에서는 괜찮을 지 모르지만 훨씬 더 풍부한 쿼리 작성을 허용하여 매우 빠르게 100 명의 접근자를 상대로 끝내고 유지 보수 또는 리팩토링에 혼란 스럽거나 오류가 발생할 수 있습니다. 인터셉터는 혼란 스러울 수 있지만 키 코드 문제가 일관성있게 실행되도록 허용합니다.하지만 저스틴의 생각은 우리가 끝낼 것에 더 가깝다고 생각합니다. – steve

답변

0

이 경우 응용 프로그램 계층과 LINQ to SQL 클래스 사이에있는 진정한 비즈니스 계층을 구축하는 것이 더 나은 솔루션이라고 생각합니다.

그런 다음 비즈니스 계층을 쿼리하면 모든 비즈니스 로직과 필터링이 구현됩니다. 적절하게 설계된 경우 비즈니스 계층은 응용 프로그램 계층을 코딩하는 사람에게 상당히 투명 할 수 있으며 모든 사람들이 행복하게됩니다.

+0

안녕 저스틴 네, 그렇게해야 할 길을 찾고 있습니다. 내 접근 방식은 다음과 같습니다 : 내 dataContext 봉인,하지만 내 데이터 개체 public (예 : linq in sql 테이블) BL에서 술어를 가져올 수있는 BL을 표현식 트리에서 추가 할 수 있습니다. 비즈니스 보안 논리. 제 프로토 타입에서는 이것이 효과적이며 처음에는 다소 혼란 스럽지만 노출되는 것은 명확하고 융통성이 있습니다. – steve

+0

응용 프로그램의 범위와 특성에 따라 전체 BL을 만드는 것은 실용적이지 않을 수 있습니다. LINQ to SQL은 자체적으로 비즈니스 규칙 유효성 검사를 모두 처리 할 수 ​​있습니다. 부분 클래스를 사용하여 ADO.NET 쿼리 인터셉터와 비슷한 목표를 달성하는 데이터 작업을 "차단"할 수 있습니다. 이 문서를 확인하십시오 : http://msdn.microsoft.com/en-us/library/bb882671.aspx – Antony