내 소프트웨어 프로젝트 중 하나에 스크립팅 언어를 포함시키고 CodeDOM을 통해 런타임에 C#을 컴파일하고 DLR 기반 스크립팅 언어를 포함하는 두 가지 옵션을 확인했습니다. 두 옵션 모두 .NET Framework에 대한 전체 액세스 권한을 제공합니다.스크립팅 작업에 C# 대신 DLR 기반 언어를 사용하는 이유는 무엇입니까?
내가 스크립팅하는 작업은 사용자 정의 된 DataRow 및 메타 데이터 집합으로 인해 수정 된 DataRow가됩니다. 나는 이러한 변환이 구성 가능하고 자주 호출 될 것으로 기대한다. 물론, 나는 변환이 최종 사용자에 의해 제공되고 수정 될 것으로 기대한다.
이러한 작업 부하를 염두에두고 한 접근법을 다른 접근법보다 명확하게 사용하면 어떤 이점이 있습니까?
사용자 입장에서는 분명히 이유가 있기 때문에 더 용감한 구문이있는 언어를 사용하는 것이 좋습니다. 그래서 DLR 기반 언어를 사용하는 것이 좋습니다. 시간과 리소스가 있다면 작고 배우기 쉬운 구문을 제공 할 수 있고 사용자가하지 말아야 할 일을하지 못하게하기 때문에 특수 DSL이 최선의 선택입니다 (예 : 파일 시스템 액세스 , 예를 들면 ...)
내가 경험 한 이야기는 할 수 없지만, DLR은 매우 빠를 수 있습니다 (IronPython은 원시 Python보다 뛰어납니다!). 하지만 동적 디스패치는 항상 약간의 오버 헤드를 수반합니다. 손에 쥐고 있으면 교차 AppDomain 호출은 꽤 비쌉니다. 동적 디스패치 비용은 스크립트 내 어디에서나 지불되지만 크로스 AppDomain 비용은 스크립트 호출 당 한 번만 지불됩니다. 어떤 것이 더 좋은지는 스크립트가 얼마나 많이 할 것인가에 달려 있습니다.
DLR 스크립팅 호스트 포함은 not difficult at all입니다. 어려운 점은 자신이 원하는대로 DSL을 돌리는 것입니다.
boo도 볼 수 있습니다. 타입 유추 덕분에 파이썬처럼 보이는 정적 인 CLI 언어입니다. 컴파일러는 확장 성이 뛰어나므로 몇 가지 작은 DSL을 작성하는 데 성공했습니다. Oren의 책 Writing DSLs with boo을 살펴볼 수도 있습니다.
두 가지 접근 방식의 상대적인 성능에 대해 의견이 있습니까? 아니면 C# 옵션에서 발생하는 AppDomain 관리 문제입니까? 또는 DLR 스크립팅 호스트를 포함하는 데 어려움이 있습니까? (좋은 지적, 나는 그것을 upvote 않았다). – Dave
"하지만 더 빠를 것입니다 ..."AppDomain 교차 메서드 호출에 대한 벌칙이 DLR 동적 디스패치 메커니즘보다 적을 것이라고 말하고 있습니까? 그 소스가 있습니까? (C# 구현에서는 컴파일 된 어셈블리를 언로드 할 수 있어야하므로 AppDomain 격리를 수행해야합니다.) – Dave
@Dave : 오, 그 문제가 있습니다 ... AppDomain을 넘을 때 벌금이 부과됩니다. 약간의 다이나믹 디스패치 비용으로 스크립트 내 어디에서나 지불 할 수 있습니다. 이러한 것들이 당신의 유스 케이스에서 어떻게 균형을 이루는 지 모르겠습니다. –