내가 읽은 표현 트리에 대한 가장 좋은 설명은 Charlie Calvert 의이 기사 입니다.
그것을 요 약하기;
식 트리를 나타내는 것을 당신이하지,하고 싶은 방법 당신이 그것을 할 싶어.
다음과 같은 매우 간단한 람다 식을 고려하십시오.
Func<int, int, int> function = (a, b) => a + b;
이 명령문은 세 섹션으로 구성됩니다.
- 선언 :
Func<int, int, int> function
- 같음 연산자 :
=
- 람다 식 :
(a, b) => a + b;
변수 는 두 숫자를 더하는 방법을 알고function 있는 원시 실행 코드를 가리 킵니다 .
이것이 대표자와 표현의 가장 중요한 차이점입니다. 전달한 두 정수로 무엇을할지 알지 못한 채 function(a Func<int, int, int>)를 호출 합니다. 2 개가 필요하고 1 개가 반환됩니다. 이는 코드가 알 수있는 최대 값입니다.
이전 섹션에서 원시 실행 코드를 가리키는 변수를 선언하는 방법을 보았습니다. 표현식 트리는 실행 가능한 코드가 아니며 데이터 구조의 한 형태입니다.
이제 델리게이트와 달리 코드 에서 표현식 트리의 기능을 알 수 있습니다 .
LINQ는 코드를 식 트리라는 데이터 구조로 변환하기위한 간단한 구문을 제공합니다. 첫 번째 단계는 Linq.Expressions네임 스페이스 를 도입하는 using 문을 추가하는 것입니다 .
using System.Linq.Expressions;
이제 표현식 트리를 만들 수 있습니다.
Expression<Func<int, int, int>> expression = (a, b) => a + b;
이전 예제에 표시된 동일한 람다식이 형식으로 선언 된 식 트리로 변환됩니다 Expression<T>. 식별자 expression 는 실행 가능한 코드 가 아닙니다 . 표현식 트리라고하는 데이터 구조입니다.
즉, 델리게이트를 호출 할 수있는 것처럼 표현식 트리를 호출 할 수는 없지만 분석 할 수 있습니다. 그렇다면 코드는 변수를 분석하여 무엇을 이해할 수 expression있습니까?
var body = expression.Body;
var parameters = expression.Parameters;
var firstParam = parameters[0];
var secondParam = parameters[1].
여기서 우리는 표현식에서 얻을 수있는 많은 정보가 있음을 알 수 있습니다.
하지만 왜 우리가 필요합니까?
식 트리가 실행 코드를 나타내는 데이터 구조라는 것을 배웠습니다. 그러나 지금까지 우리는 왜 그러한 전환을 원하는지에 대한 핵심 질문에 답하지 않았습니다. 이것은이 게시물의 시작 부분에서 우리가 물었던 질문이며 이제 대답 할 시간입니다.
LINQ to SQL 쿼리는 C # 프로그램 내에서 실행되지 않습니다. 대신 SQL로 변환되어 유선을 통해 전송되고 데이터베이스 서버에서 실행됩니다. 즉, 다음 코드는 실제로 프로그램 내에서 실행되지 않습니다.
var query = from c in db.Customers where c.City == "Nantes" select new { c.City, c.CompanyName };
먼저 다음 SQL 문으로 변환 된 다음 서버에서 실행됩니다.
SELECT [t0].[City], [t0].[CompanyName] FROM [dbo].[Customers] AS [t0] WHERE [t0].[City] = @p0
쿼리 식에서 찾은 코드는 다른 프로세스에 문자열로 보낼 수있는 SQL 쿼리로 변환되어야합니다. 이 경우 해당 프로세스는 SQL 서버 데이터베이스가됩니다. 원시 IL 또는 실행 코드를 SQL로 변환하는 것보다 표현식 트리와 같은 데이터 구조를 SQL로 변환하는 것이 훨씬 쉬울 것입니다. 문제의 난이도를 다소 과장하려면 일련의 0과 1을 SQL로 변환하는 것을 상상해보십시오!
쿼리 식을 SQL로 변환 할 때가되면 이전 섹션에서 간단한 람다 식 트리를 분리 한 것처럼 쿼리를 나타내는 식 트리를 분리하고 분석합니다. 물론 LINQ to SQL 식 트리를 구문 분석하는 알고리즘은 우리가 사용한 것보다 훨씬 정교하지만 원칙은 동일합니다. 식 트리의 일부를 분석 한 후 LINQ는이를 검토하고 요청 된 데이터를 반환 할 SQL 문을 작성하는 가장 좋은 방법을 결정합니다.
쿼리 식과 같은 코드를 다른 프로세스에 전달하여 실행할 수있는 문자열로 변환하는 작업을 만들기 위해 식 트리가 만들어졌습니다. 그렇게 간단합니다. 여기에는 큰 수수께끼가 없으며 흔들어야 할 마술 지팡이도 없습니다. 코드를 가져 와서 데이터로 변환 한 다음 데이터를 분석하여 다른 프로세스로 전달할 수있는 문자열로 변환 될 구성 요소를 찾습니다.
쿼리는 이러한 추상 데이터 구조로 캡슐화 된 컴파일러에 전달되기 때문에 컴파일러는 원하는 거의 모든 방식으로 자유롭게 해석 할 수 있습니다. 특정 순서 또는 특정 방식으로 쿼리를 실행하도록 강요되지 않습니다. 대신 표현식 트리를 분석하고 원하는 작업을 찾은 다음 수행 방법을 결정할 수 있습니다. 적어도 이론적으로는 현재 네트워크 트래픽, 데이터베이스의 부하, 사용 가능한 현재 결과 집합 등과 같은 여러 요소를 자유롭게 고려할 수 있습니다. 실제로 LINQ to SQL은 이러한 요소를 모두 고려하지 않습니다. 하지만 이론적으로는 원하는 것을 거의 할 수 있습니다. 또한이 식 트리를 직접 작성한 사용자 지정 코드에 전달할 수 있으며이를 분석하여 LINQ to SQL에서 생성 된 것과 매우 다른 것으로 변환 할 수 있습니다.
다시 한 번, 표현 트리를 통해 우리 가 원하는 것을 표현 (표현?) 할 수 있음을 알 수 있습니다. 그리고 우리 는 표현이 어떻게 사용 되는지 를 결정 하는 번역자를 사용합니다.