.NET에서 오류 코드/메시지 관리에 대한 접근 방식

Question

다중 계층 응용 프로그램에서 오류 코드 및 메시지를 관리하기위한 제안/모범 사례를 찾고 있습니다. 구체적으로는 다음과 같습니다.

1. 어디에서 오류 코드를 정의해야합니까? 열거? 수업?
2. 오류 메시지 또는 오류 코드와 관련된 세부 정보는 어떻게됩니까? 리소스 파일? enum 값에 대한 속성 등?
3. 예를 들어 DAL, BLL, UI 및 공통 프로젝트로 구성된 다중 계층 응용 프로그램이있는 경우 모든 계층에 대해 하나의 거대한 코드 목록이 있거나 프로젝트/계층별로 확장 가능한 코드가 있어야합니까?

업데이트 : 중요이 응용 프로그램에 대한 몇 가지 클라이언트가 웹 서비스 (SOAP & REST) ​​

를 통해 것 같이 내가 전적으로 오류보고에 대한 예외 및 사용자 정의 예외 유형에 의존 할 수 있음을 언급 어떤 제안을 환영합니다!

Answer 1

나는 일반적인 프로젝트 (또는 애플리케이션 프레임 워크 프로젝트)를 작성하고 예외 그것에 공통 객체을 넣어 더 나은 생각합니다.

그리고 명백한 당신이 클래스를 넣어야 할

당신의 클래스 (- - PageBase 등 MasterBase- ModuleBase 특별히 UI)에 대한 기본 클래스를 포함하는 애플리케이션 프레임 워크를 가지고 항상 좋은 생각입니다 그리고 BLL 프로젝트의 Enums.

3 계층 은 3 프로젝트를 의미하지 않습니다. BLL에 5 개의 프로젝트가있을 수 있습니다.

마지막으로 ELMAH 또는 다른 유사한 도구를 사용하는 것을 잊지 마십시오.

Answer 2

오류 코드는 오래된 skool이므로 오래된 예외 인 COM 및 C 프로그래밍 환경, 예외를 지원하지 않는 환경에서 오류 코드가 필요했습니다. 요즘 예외를 사용하여 클라이언트 코드 또는 사용자에게 문제를 알립니다. .NET의 예외는 자체 설명 적이며 형식, 메시지 및 진단을 갖고 있습니다.

합리적으로 복구 할 수있는 예외와 정확히 무엇이 잘못되었는지 또는 어떻게 복구되었는지 알 수없는 두 가지 유형의 예외를 구별해야합니다. 후자의 종류가 가장 보편적인데, 당신은 시정 조치를 취하기 위해 인간이 필요합니다. 표준 내장 .NET 예외 유형 중 하나를 사용하여 이러한 예외를 발생시킵니다. IllegalOperationException, FormatException, ArgumentException은 일반적인 선택입니다. 그러한 예외를 발생시키는 것이 백 엔드 인 경우 변경하지 않고 통과해야합니다. 보통 내부 상태가 일관성을 유지할 수 있도록 finally 블록이 필요하며, 경우에 따라 복구 상태를 단순하게 포함하는 catch 블록이 필요할 수 있습니다.

복구 가능한 것으로 간주되는 항목은 Exception 클래스에서 파생 된 사용자가 직접 선언 한 예외 유형으로 발생되어야합니다. 이를 통해 코드 업스트림에 catch 절을 작성하고 의미있는 작업을 수행 할 수 있습니다. 문제를 설명하는 메시지를 생성해야합니다. 업 스트림 코드가 실제로 처리하지 못하는 경우 하드 코딩 된 문자열이나 리소스에서 메시지의 텍스트를 가져와야합니다. 현지화 지원.