FXCOP의 CollectionProperTiesshouldBereadonly 규칙은 스프링 프레임 워크와 호환되지 않습니까?

Question

fxcop은 다음과 같습니다 CollectionPropertiesshouldBereadonly 규칙 클래스에 클라이언트가 설정할 수있는 일종의 컬렉션 속성이있는 경우 불만을 제기합니다. 대신, 속성을 읽기 전용으로 만들고 Clear () 메소드 및 addrange () 메소드를 컬렉션의 내용을 변경하기위한 메소드를 제공 할 것을 제안합니다.

나는 더 깨끗하고 통제 된 인터페이스를 만들 수 있다는 데 동의하지만, 스프링 프레임 워크와의 인터페이스를 작동시키기 위해 고군분투하고 있습니다. 공동 작업자 모음으로 객체를 구성하려면 공동 작업자를 주입하기 위해 수집 속성을 노출시켜야합니다. 나는 조사했다 스프링 문서, 그리고 나는 Spring에게 addRange () 메소드를 호출하도록 알리는 방법을 볼 수 없습니다. 뭔가 누락 되었습니까?

지금은 스프링 구성에 필요하다는 메모와 함께 경고를 제외 할 것입니다.

업데이트: 지난 2 개월 동안 여기에 니블을 얻지 못했기 때문에 같은 질문을 게시했습니다. FXCOP 포럼.

Answer 1

컬렉션 속성에 Getter가 노출 된 경우, 귀하가 목록에 사용 된 FXCOP 권장 패턴을 사용하고 컬렉션에 추가한다고 가정합니다. 첫 번째 패턴도 지원됩니다.

일반 컬렉션의 경우 노출 된 속성이 ILIST 유형 인 경우에만 작동합니다. 우리는 a 지라 문제 다음 릴리스 가이 문제를 해결하려면. BTW, 이것은 기본 클래스 라이브러리에서 매우 일반적인 패턴입니다 (아마 아시다시피 ...).. .

건배, 마크

Answer 2

당신이 생각하는 것만 큼 문제가 나쁜가요? 내 이해는 다음과 같은 읽기/쓰기 속성이 있으면 fxcop이 불만을 제기한다는 것입니다.

public List<Foo> Items { get; set; }

... 수업 사용자가 다음을 수행 할 수 있기 때문에 다음과 같습니다.

myInstance.Items = new List<Foo>();

분명히 당신은 수업 사용자가 목록을 완전히 재 할당하기를 원하지 않습니다. 따라서 FXCOP는이 패턴을 권장합니다.

private List<Foo> _items = new List<Foo>();
public List<Foo> Items { get { return _items; } }

따라서 이제 수업 사용자는 새로운 목록 인스턴스로 덮어 쓰는 대신 목록에서 항목을 추가하고 제거 할 수 있습니다.

Spring.net은 수집 속성을 어떻게 구현합니까? 그들은 내 첫 번째 예처럼 실제로 읽거나 쓰는가? 그렇다면, 그러한 패턴에 대한 사용 사례를 보는 것은 흥미로울 것입니다. 왜냐하면 그것이 옳지 않은 것처럼 보이기 때문입니다.