내 설계는 일반적으로 DAO 레이어가 어떤 예외도 처리하지 않는다는 것입니다. 서비스 레이어는 DAO 레이어를 호출하고 예외를 포착한 다음 상태 코드를 통해 해당 정보를 액션 레이어에 반환합니다. 개인적으로 Action 레이어의 로직은 최대한 단순해야 한다고 생각합니다. Action은 인터페이스 레이어이고 인터페이스가 제공하는 기능을 한눈에 살펴보기에는 너무 복잡하기 때문입니다.
오류 코드는 절차적 언어에서 매우 일반적이지만 객체 지향 절차에서는 예외를 좀 더 처리하기 위해 사용됩니다. 오류 코드 사용의 단점은 다음과 같습니다. 1. 오류 감지가 필수는 아닙니다. 2. 코드는 다양한 if else 오류 코드 판단으로 가득 차 있습니다. 예외 사용의 장점은 다음과 같습니다. 1, 오류 감지는 필수이며 예외를 처리하거나 발생시켜야 합니다 2. 코드는 다양한 상태 코드를 판단할 필요가 없습니다. 예외가 발생하면 작업을 종료하기 위해 직접 발생합니다. 오류를 추적하는 스택입니다.
이것은 주로 두 가지 사항에 달려 있다고 생각합니다. 1. 각 레이어의 로직 양은 스스로 선택해야 합니다. 2. 개인 스타일이므로 비즈니스 레이어에서 최대한 처리하는 것을 선호하지만 dao는 레이어에서는 예외만 발생합니다. 실제로 클라이언트에 직접 반환되지 않는 한 어디에서나 처리할 수 있습니다.
비즈니스 레이어는 else if입니다. 기본적으로 데이터를 반환하기 전에 기본값을 설정해야 합니다. 예를 들어 dao 클래스만 비즈니스 레이어 이외의 시스템과 상호 작용할 수 있습니다. 데이터베이스와 네트워크가 더 크므로 dao에 있어야 합니다. 예외 비즈니스 계층/작업은 클래스에서 null/기본값을 올바르게 반환하므로 사용자에게 더 친숙합니다.
지속성은 일반적으로 논리적 처리를 거치지 않습니다. 상위 수준에 던지는 것이 가장 좋습니다. 그렇지 않으면 나중에 이식하기가 너무 번거로울 것입니다. 예외가 발생하는 상황은 사용자에게 좋지 않습니다. 결과적으로 성공하지 못한 이유는 개발자에게 맡기므로. 그렇게 많은 종류의 결과를 반환할 필요는 없고, 그냥 예외를 직접 반환하면 된다고 생각합니다. 개발자들은 어떤 예외가 발생했는지 보고 원인을 판단할 수도 있습니다. 이것을 기록하여 어디에서 오류가 발생했는지 확인하고 싶으신가요? 인쇄 로그는 다음과 같아야 합니다. 로그에 예외 등을 추가하는 것은 매우 일반적인 관행입니다.
귀하의 예에서는 중요하지 않지만 그러나 사물이 있을 때는 중요합니다. 선언적 사물을 사용하는 경우 트랜잭션의 중간 링크에서 오류가 발생합니다. 을 직접 던지기 때문에 트랜잭션이 시작된 수준에서 잡을 수 있고, 현재 트랜잭션의 모든 작업을 롤백할 수 있다. dao에서 예외를 잡았다면 감지하는 것이 매우 번거로울 것이다. 비즈니스를 롤백해야 하는지 여부. 각 dao 작업의 결과를 판단해야 합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
내 설계는 일반적으로 DAO 레이어가 어떤 예외도 처리하지 않는다는 것입니다. 서비스 레이어는 DAO 레이어를 호출하고 예외를 포착한 다음 상태 코드를 통해 해당 정보를 액션 레이어에 반환합니다.
개인적으로 Action 레이어의 로직은 최대한 단순해야 한다고 생각합니다. Action은 인터페이스 레이어이고 인터페이스가 제공하는 기능을 한눈에 살펴보기에는 너무 복잡하기 때문입니다.
오류 코드는 절차적 언어에서 매우 일반적이지만 객체 지향 절차에서는 예외를 좀 더 처리하기 위해 사용됩니다.
오류 코드 사용의 단점은 다음과 같습니다.
1. 오류 감지가 필수는 아닙니다.
2. 코드는 다양한 if else 오류 코드 판단으로 가득 차 있습니다.
예외 사용의 장점은 다음과 같습니다. 1, 오류 감지는 필수이며 예외를 처리하거나 발생시켜야 합니다
2. 코드는 다양한 상태 코드를 판단할 필요가 없습니다. 예외가 발생하면 작업을 종료하기 위해 직접 발생합니다. 오류를 추적하는 스택입니다.
라이브러리에서 예외가 발생하고 비즈니스에서 오류 코드를 반환합니다.
이것은 주로 두 가지 사항에 달려 있다고 생각합니다. 1. 각 레이어의 로직 양은 스스로 선택해야 합니다. 2. 개인 스타일이므로 비즈니스 레이어에서 최대한 처리하는 것을 선호하지만 dao는 레이어에서는 예외만 발생합니다. 실제로 클라이언트에 직접 반환되지 않는 한 어디에서나 처리할 수 있습니다.
비즈니스 레이어는 else if입니다. 기본적으로 데이터를 반환하기 전에 기본값을 설정해야 합니다. 예를 들어 dao 클래스만 비즈니스 레이어 이외의 시스템과 상호 작용할 수 있습니다. 데이터베이스와 네트워크가 더 크므로 dao에 있어야 합니다. 예외 비즈니스 계층/작업은 클래스에서 null/기본값을 올바르게 반환하므로 사용자에게 더 친숙합니다.
지속성은 일반적으로 논리적 처리를 거치지 않습니다. 상위 수준에 던지는 것이 가장 좋습니다. 그렇지 않으면 나중에 이식하기가 너무 번거로울 것입니다.
예외가 발생하는 상황은 사용자에게 좋지 않습니다. 결과적으로 성공하지 못한 이유는 개발자에게 맡기므로. 그렇게 많은 종류의 결과를 반환할 필요는 없고, 그냥 예외를 직접 반환하면 된다고 생각합니다. 개발자들은 어떤 예외가 발생했는지 보고 원인을 판단할 수도 있습니다.
이것을 기록하여 어디에서 오류가 발생했는지 확인하고 싶으신가요? 인쇄 로그는 다음과 같아야 합니다. 로그에 예외 등을 추가하는 것은 매우 일반적인 관행입니다.
중첩 수준은 몇 개인가요?
먼저 중첩을 줄이는 방법 알아보기
또한 서비스 레이어는 예외 및 비즈니스 로직을 처리하는 특정 결과를 반환합니다.
액션 레이어는 라우팅 역할을 합니다. 서비스를 호출하여 직접 반환하면 됩니다.
Zhihu에 이런 질문을 했습니다: https://www.zhihu.com/question/36278363
참고해주세요.
귀하의 예에서는 중요하지 않지만
그러나 사물이 있을 때는 중요합니다.
선언적 사물을 사용하는 경우 트랜잭션의 중간 링크에서 오류가 발생합니다. 을 직접 던지기 때문에 트랜잭션이 시작된 수준에서 잡을 수 있고, 현재 트랜잭션의 모든 작업을 롤백할 수 있다.
dao에서 예외를 잡았다면 감지하는 것이 매우 번거로울 것이다. 비즈니스를 롤백해야 하는지 여부. 각 dao 작업의 결과를 판단해야 합니다.