나는이 answer (강조 광산)를 참조하고 있습니다 :프로덕션 환경에 코드 계약을 배포하는 것이 좋지 않습니까?
는 ContractClass에서 살펴보고 ContractClassFor 속성. 이를 통해 별도의 어셈블리에 코드 계약을 포함한 클래스를 작성할 수 있습니다. 이 코드를 복잡하게하지 않고, 당신이 dev에 작업에 사용할 수있는 계약을 할 수 있으며 또한 왜 원하지 않을 것이다 라이브 코드
와 계약을 배포 할 필요가 없습니다 의미 배치 된 계약?
모범 사례 관점에서 개발과 품질 관리를위한 계약입니까?
당신은 일반적으로 릴리스 빌드에 사후 계약을 배포하고 싶지 않아요. 이는 귀사가 귀사의 책임하에있는 오류로 귀사의 어셈블리를 사용하는 사람들과 대면하지 않도록하기위한 것입니다. 나는 다른 이유가있을 것이라고 확신하지만 이것은 내 마음에 떠오르는 첫 번째 것이다.
현재 코드 계약과 관련하여 알고있는 최고의 모범 사례는 없습니다. 코드 계약 (코드 계약 사용자 설명서에 설명되어 있음)을 사용하는 방법에는 여러 가지가 있으며, 각각 고유 한 지침이 있습니다.
내가 언급 한대로 귀하가 참조하는 대답은 완전히 정확하지 않습니다.
이걸 똑바로 세워 줘. 응용 프로그램의 어셈블리 나 최종 사용자를 사용하는 사람들이 자신의 책임이나 책임하에 오류를 직면하게하고 싶지는 않습니까? 따라서 솔루션은 계약을 해제하고 전체 시스템에서 오류가 발생하여 기본 데이터가 손상 될 수 있습니다. 무서운! 개인적으로 나는 석방 후 처음 몇 달 동안 전체 계약을 맺고, 성능이 문제라면 덜 중요한 계약을 해제 할 것입니다. 코드에 숨어있는 문제가 그들을 떠나 버리는 것은 아닙니다. – rvdginste
코드가 정상적으로 '문제'를 처리하고 가능한 경우 유효한 상태로 되돌려 야합니다. 나는 앱의 사용자에게 ContractException을 던지거나 api가 문제를 정상적으로 처리하지 못하는 것을 발견했다. 충족되지 않은 선행 조건은 Contract.Requires
나는 당신의 요점을 본다. 그러나 나의 의견은 그 경우에 전제 조건이 아니라는 것이다. ContractException이 발생하면 개발자가 실수를 저지른 것입니다. 정상적으로 처리해야하는 문제가있는 경우에는 예외적 인 경우이므로 정상적인 예외를 사용해야합니다. 이러한 예외적 인 경우는 "사양대로"간주됩니다. 계약 위반은 사양을 벗어난 것으로 간주됩니다. 그러나 물론, 그건 내 의견이다. – rvdginste
여기는 정말 좋은 질문입니다. 나는 최근에 같은 질문을했다. – itsmatt