2013-12-23 2 views
3

MassTransit의 소비자 인터페이스는 모두 메시지 모델이 구조체가 아니라 클래스 일 것으로 기대합니다.MassTransit 메시징에서 구조체가 허용되지 않는 이유는 무엇입니까?

/// <summary> 
/// Declares a Consume method for the message type TMessage which is called 
/// whenever a a message is received of the specified type. 
/// </summary> 
public static class Consumes<TMessage> where TMessage : class 

이이 기술을 밖으로 시작하는 사람들을위한 문제가 아니다 : 그들은 모두 내부 인터페이스 (거기에 아주 좋은 디자인은 내가 말을해야) 때문에,이 직접 from the source code 촬영 제약을 보여주는 일반 컨테이너 클래스이며, 하지만 서비스 버스 프레임 워크의 사용을 고려하기 전에 이미 코드베이스에 명령 패턴과 관련된 객체가 있었기 때문에 우리에게는 번거로 웠습니다. 따라서이 제약 조건을 추가하기 위해 상당한 수의 인터페이스와 일반 클래스를 변경해야했습니다 MT와 함께 일할 수 있도록

struct 유형이 명시 적으로 없기 때문에 운이 좋았습니다. 그럴 경우 더 많은 (아마도 원치 않는) 변경이 발생할 수 있기 때문입니다.

왜 메시지 클래스가 class일까요? 라이브러리를 기존 코드와 더 원활하게 인터페이스 할 수 있도록 변경하는 것이 가능합니까? 제약 조건이 아무 것도 추가되지 않았다는 것을 알았으므로 아마도 몇 가지 합병증이있을 것입니다.

답변

1

사실 모든 메시지 계약은 인터페이스 여야합니다. 추상화는 모든 논리에서 제거되어야하며 인터페이스는이를 적용 할 것입니다. MT가 상속/구현 계층에서 일치하는 모든 경로에 전달하므로 흥미로운 방식으로 전달을 작성할 수도 있습니다.

하지만 메시지에 대해 제안하는 것과 관계없이 값 유형은 우리가 사용하는 방식대로 작동하지 않습니다. 우리는 유형 정보에 크게 의존하며 고객에게 제공되는 유형에 대한 프록시를 만들 수 있습니다.

관련 문제