왜 .Net 세계가 정적으로 유형이 지정된 대안 대신 마술 문자열을 사용하는 것처럼 보입니까?


47

그래서 저는 .Net에서 일합니다. .Net에서 오픈 소스 프로젝트를 만듭니다. 내 가장 큰 문제 중 하나는 .Net의 필요성이 아니라 주변의 커뮤니티 및 프레임 워크입니다. 마법의 이름 지정 체계와 문자열이 모든 것을 수행하는 가장 좋은 방법으로 취급되는 것처럼 보입니다. 대담한 진술이지만 살펴보십시오.

ASP.Net MVC :

안녕하세요 세계 노선 :

        routes.MapRoute(
            "Default",                                              // Route name
            "{controller}/{action}/{id}",                           // URL with parameters
            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
        );

이것이 의미하는 것은 ASP.Net MVC가 어떻게 든 HomeController코드에서 조회된다는 것 입니다. 어떻게 든 새로운 인스턴스를 만든 다음 일종의 매개 변수를 Index 사용하여 분명히 함수를 호출합니다 id. 그리고 다음과 같은 다른 것들이 있습니다.

RenderView("Categories", categories);
...or..
ViewData["Foobar"]="meh";

그리고 XAML에도 비슷한 것들이 있습니다. DataContext은 대상으로 취급되며 원하는 유형으로 해석되기를 희망하고기도해야합니다. DependencyProperties는 마법의 문자열과 마법의 명명 규칙을 사용해야합니다. 그리고 이런 것들 :

  MyData myDataObject = new MyData(DateTime.Now);      
  Binding myBinding = new Binding("MyDataProperty");
  myBinding.Source = myDataObject;

캐스팅 및 다양한 마술 런타임 지원에 더 의존합니다.

어쨌든, 나는 여기서 끝까지 모든 것을 말합니다 : 왜 이것이 .Net 세계에서 그렇게 잘 견딜 수 있습니까? 정적 유형의 언어를 사용하여 거의 항상 유형이 무엇인지 알지 못합니까? 리플렉션과 타입 / 메소드 / 속성 / 어떤 이름 (문자열)이 제네릭이나 델리게이트 또는 코드 생성에 비해 선호되는 이유는 무엇입니까?

ASP.Net의 라우팅 구문이 경로를 처리하는 방법을 실제로 해결하기 위해 거의 독점적으로 리플렉션에 의존하는 이유에 대해 내가 누락 된 이유가 있습니까? 메서드 또는 속성의 이름을 변경하면 갑자기 문제가 발생하지만 갑자기 해당 메서드 또는 속성에 대한 참조가 없으며 컴파일러 오류가 없습니다. 왜 마술 현의 편의가 "가치"로 간주 되었습니까?

나는 일반적으로 어떤 것들에 대해 정적으로 유형이 지정된 대안이 있다는 것을 알고 있지만, 일반적으로 뒷좌석을 가지고 자습서 또는 다른 초보자 자료에는 결코없는 것 같습니다.


14
무의미한 역동 성은 우리 CPU가 그것을 실행할만큼 빠르기 때문에 모든 분노가되었습니다.
DeadMG

7
어떻게 요? LINQ에서는 그러한 예를 보지 못했습니다.
DeadMG

6
내 겸손한 추측은 올바르게 정적으로 입력 된 대안이 너무 불편하다는 것입니다. 그것은 대부분의 유형 시스템에서 많은 부분을 차지하는 주제입니다. "우리는 유형 시스템에서이 작업을 수행하고 싶지만 표현력이 충분하지 않습니다." (또는 그 반대의 경우 : "우리는 이것을 타이프 시스템에서 성공적으로 표현했지만 세 번이나 복잡하게 만들었습니다.") @ GlenH7 모든 LINQ에 익숙하지는 않지만 사용했던 비트는 표시되지 않습니다. 이 게시물에서 설명하는 내용에 가까운 내용 예를 들어 주시겠습니까?

2
@Earlz 더 중요한 것은 익명의 객체가 정적으로 입력된다는 것입니다. 마술 문자열은 없으며 컴파일러는 관련된 모든 이름과 유형을 알고 있습니다. 의 다른 모든 사용을 위해 저장하십시오 var.

1
@Earlz는 흥미롭지 만 람다 구문이 추가 부풀림이라고 주장 할 수 있습니다. 내 생각 엔 매직 스트링 / 컨벤션 방식을 사용했다. 왜냐하면 많은 사람들에게 "충분히 좋은"데드로 죽었 기 때문이다. 그들은 항상 툴링을 조정하여 어떤 지침 / 안전을 제공 할 수있다. IMHO는 안전과 편의 사이의 절충입니다. 역동적 인 ViewBag를 사용하면이 정신을 암시합니다 (전적으로 동의하지는 않습니다).
Daniel B

답변:


31

실제로 .NET 세계에서는 언급 한 바로 이러한 것들에 대한 반발이 있습니다. 그러나 첫 번째 예에서는 라우팅 엔진에 기본 경로를 매핑하는 규칙이 제공됩니다. 경로가 동적이기 때문에 정적 구성을 사용하는 것이 거의 불가능합니다.

또한 XAML / WPF에 대해서도 언급했습니다. 둘 다 제네릭이 .NET에 도입되기 훨씬 전에 개발 중이며 제네릭을 지원하기 위해 다시 돌아 가면 이미 매우 늦은 제품 (Longhorn / Vista)이 더 지연 될 수 있습니다.

ASP.NET MVC 프레임 워크에는 매직 문자열 대신 람다 식을 사용하는 예제가 있으며 Entity Framework / LINQ는 언어와 프레임 워크가 정적 객체 그래프를 통해 SQL 쿼리를 작성하는 기본 지원을 제공하는 곳에서 한층 더 발전시킵니다 (구성하는 대신) 마술 SQL 문자열, 쿼리의 컴파일 시간 유효성 검사를 얻습니다).

정적 구성의 다른 예는 런타임에 객체 그래프를 검사해야하지만 개발자가 람다 식을 사용하여 힌트를 정적으로 제공 할 수 있도록하는 구조 맵 및 기타 최신 종속성 주입 컨테이너 및 기타 프레임 워크를 참조하십시오.

따라서 짧은 대답은 역사적으로 .NET은 3.5 릴리스까지 객체 그래프의 정적 순회를 지원하지 않았다는 것입니다. 이제 우리는 그것을 가지고 있기 때문에 많은 개발자들이 마술 문자열보다 그것을 선호하고 많은 사람들이 typeOf 연산자와 비슷한 symbolOf 연산자와 같은 더 깊은 지원을 추진하고 있습니다.


3
XAML은 장황합니다 ... 제네릭에 대한 지원을 추가하면 더 많은 것을 만들 수 있습니다 (예, 전체 XAML이 인간 인수를 위해 만들어진 것이 아니라는 것을 알고 있습니다). 게다가 XAML은 실제 프로그래밍 언어보다 HTML과 더 유사하다고 생각합니다. 표시하는 객체의 유형에 신경 쓰지 말고 표시하는 방법 만 신경 쓰십시오.
Michael Brown

2
제네릭은 2.0에 도착했지만 3.5 (LINQ 포함)까지 Expressions를받지 못했습니다. 표현은 LINQ와 커뮤니티가 그 힘을 가져다가 실행하는 힘입니다. 이 기술은 정반사라고합니다
Michael Brown

1
정적 반사에 대한 좋은 지적. 나는 3.5에서 소개 된 것을 잊었다
Earlz

2
이것은 훌륭한 답변이며 푸시 백에 동의합니다. 오타 나 버그가있는 경우 런타임에만 잡히므로 쉽게 놓칠 수 있기 때문에 전염병처럼 피해야 할 모든 것들이 있습니다. 또한 리팩토링을 매우 다르게 만듭니다. 피하십시오 피하십시오!
Rocklan

2
푸시 백에 동의하십시오. T4MVC 는 많은 문자열을 제거하고 강력한 형식의 코드로 대체하려는 열망을 떠올리게 하는 프로젝트입니다.
Carson63000
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.