2년 동안 MVC를 공부했지만 아직 개념이 모호한 부분이 있어서 여기서 답을 찾을 수 있었으면 좋겠습니다.
컨트롤러는 데이터 처리에 대한 책임이 없으며 모든 것이 당사 서비스에 의해 처리된다고 말하는 사람을 본 적이 있습니다. 웹 페이지의 프런트 엔드에서 반환되는 데이터 유형이 무엇이든 해당 데이터 유형은 서비스로 직접 전달되며, 그런 다음 서비스가 이를 처리하지만 때로는 여러 서비스가 동시에 호출된다는 또 다른 의견이 있습니다. 개체가 컨트롤러에 캡슐화되어 있으면 서비스 메서드에서 여러 번 호출되지 않습니다.
또 다른 질문은 컨트롤러와 서비스 간의 상호 작용에 관한 것입니다.
프런트 엔드에서 원활한 고객 상호 작용을 보장하기 위해 사용자 이름이 이미 존재하거나 사용자 이름과 비밀번호가 일치하지 않는 등 일부 오류 메시지가 컨트롤러를 통해 프런트 엔드에 반환되는 경우가 많습니다. 하지만 서비스 레이어에서 비즈니스 로직을 처리합니다. 로그인(String 사용자 이름, 문자열 비밀번호) 메서드의 반환 값을 boolean으로 설정하면 여러 오류를 반환할 수 없습니다. 그러나 String 유형을 반환하는 경우에는 다음을 수행해야 합니다. 몇 가지 기본 설정을 설정합니다.
저만의 "멋진 아이디어"는 서비스에서 일부 사용자 정의 RuntimeException을 던진 다음 컨트롤러에서 TryCatch를 사용하여 다양한 오류를 처리하는 것입니다. 그러나 예외를 던지는 이러한 방식은 부적절하다고 생각합니다. 나는 최근 혼란스러워서 다음 프로젝트 작업을 시작하려고 합니다. 내 혼란을 해결하는 데 도움이되기를 바랍니다.
감사합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
우리 프로젝트는 세 가지 레벨로 구분됩니다:
프레젠테이션 레이어: Spring MVC, HTTP 요청 수신, 결과 표시(반환) 및 간단한 확인을 담당합니다.
앱 레이어: 가져오기, 내보내기, 복합 검증 등의 애플리케이션 레이어 기능 제공
도메인 레이어: 일부 서비스와 같은 비즈니스 로직을 처리합니다
호출 순서는 단일: 컨트롤러->앱->도메인
그리고 인식 관계는 컨트롤러->앱->도메인, 즉 하위 레이어가 상위 레이어를 인식하지 못합니다
첫 번째 질문에 먼저 답변해 드리겠습니다.
당신이 언급한 첫 번째 질문은 Http에서 요청한 매개변수가 객체가 아니라 여러 기본 유형이지만 서비스에서 수신한 매개변수는 객체라는 뜻으로 이해해도 될까요? 올바른 접근 방식은 "원시" 매개변수를 컨트롤러의 개체 개체로 변환한 다음 서비스를 호출하는 것입니다.
이게 왜 맞나요? 서비스는 비즈니스 로직을 포함하는 도메인 계층에 속하므로 서비스가 받아들이는 매개변수는 사용자의 필요에 따라 설계해야 합니다. 그래야 다른 시나리오에서 재사용할 수 있습니다.
예를 들어 서비스는 다양한 프레젠테이션 계층 환경에서 재사용 가능해야 합니다.
웹 프로그램에서는 사용자가 전달한 매개변수가 POST/GET 형식으로 전달됩니다.
웹 서비스 프로그램에서 사용자가 전달하는 매개변수는 json 또는 SOAP입니다
Swing 프로그램에서 사용자가 전달하는 매개변수는 문자열입니다.
서비스를 특정 프리젠테이션 계층 환경에 바인딩하면 메서드 매개변수가 확실히 불안정해 재사용이 불가능해집니다.
마찬가지로 Service의 반환 값도 특정 시나리오에 구속되어서는 안 됩니다.
Spring MVC 레벨에서 컨트롤러는 매개변수를 관련 문서인 객체로 쉽게 변환할 수 있습니다
두 번째 질문:
이 질문은 세 가지로 나눌 수 있습니다.
1) 매개변수 길이 제한, 비어있지 않은 판단 등 간단한 검증은 어디서 하나요?
Spring MVC 자체에서 제공하는 메커니즘과 관련문서, 관련문서를 이용하여 간단한 검증을 진행합니다
2) 주문 시 사용자 계정의 비활성화 여부를 확인하는 등 서비스 자체의 비즈니스 로직과 병행하여 확인이 수행되는 곳은 어디입니까
저는 앱 계층에서 이러한 논리적 검사를 수행하는 경향이 있습니다. 컨트롤러는 앱을 호출하고 앱은 비즈니스를 함께 엮기 위해 두 가지 다른 서비스를 호출합니다.
3) 서비스 자체와 관련된 비즈니스 로직을 확인하는 방법
로그인의 예를 들어주셨습니다. 예외를 사용하여 호출자(Controller)에게 처리 결과를 알려주는 데에는 문제가 없습니다. 이 목표를 달성하기 위해 서비스의 반환 값을 강화할 수도 있지만 서비스의 반환 값 설계는 프레젠테이션 계층 환경에 바인딩될 수 없으며, 그렇지 않으면 재사용할 수 없다는 점에 유의해야 합니다. 이것이 @YaTou가 apache-shiro를 언급한 이유입니다. 인증 실패를 처리하기 위해 예외 메커니즘이 사용됩니다. 왜냐하면 이것만으로도 충분히 일반적이기 때문입니다.
Controller는spring-mvc에서 재사용할 수 없기 때문에Controller가 데이터 처리를 담당하지 않는 것이 맞다고 생각합니다. 비즈니스 로직이서비스로 추상화되면 이서비스를 재사용할 수 있습니다.Controller不负责处理数据是正确的, 因为在spring-mvc中Controller是不能复用的, 但是如果你把业务逻辑抽象成Service, 那么这个Service就是可以复用的.至于你说的 "在Controller就将对象封装好了，就免于在Service的方法中多次封装" , 没太明白什么意思, 你每个
Service需要什么参数,Controller就给什么参数, 至于需要的参数是否需要封装成对象就可以自己权衡了.你所说的
"컨트롤러에서 개체를 캡슐화하면 서비스 메서드에서 여러 번 캡슐화할 필요가 없습니다"라고 말씀하셨는데, 각 에 어떤 매개변수가 필요한지 잘 모르겠습니다. 서비스? 컨트롤러는 매개변수만 제공합니다. 필요한 매개변수를 객체에 캡슐화해야 하는지 여부는 직접 측정할 수 있습니다.🎜 🎜login(String username,String password), 你想抽象成Service用异常处理处理多种不同的结果, 这个我觉得完全没有问题, 而且我觉得非常好啊, 很多认证框架都用的这种方式, 至少我看的apache-shirologin(String username,String Password)에 대해 말씀하신 내용을Service로 추상화하고 예외 처리를 사용하여 여러 다른 결과를 처리하려는 것은 없다고 생각합니다. 그리고 저는 이것이 매우 좋다고 생각합니다. 적어도 제가 본apache-shiro는 다양한 인증 실패 상황을 처리하기 위해 예외를 사용합니다.첫 번째 질문에는 정해진 답이 없다고 생각합니다. 구체적인 상황을 분석하고 논리 레이어링을 명확하고 유지하기 쉽게 만드는 것이 좋습니다.
두 번째 질문의 경우, 여기서 제공한 상호작용에는 권한 제어가 적용됩니다. 일반적으로 필터, AOP, 프록시, 리플렉션 등을 사용하여 코드 클로저를 구현할 수 있습니다. 이러한 중앙 제어 코드에도 예외가 있습니다. 한 번만 던져도 되지만 컨트롤러에서 직접 하드코딩하기는 번거롭습니다. 서비스 계층은 여러 테이블과 관련된 복잡한 비즈니스 논리 처리를 구현하기 위해 Dao 계층 메서드를 호출하는 것에 관한 것입니다. 트랜잭션도 이 계층에 배치되므로(물론 프레임워크는 이제 이 모든 작업을 수행했습니다) 서비스 계층은 일반적으로 그렇지 않습니다. 예외 발생(매개변수 확인은 Controller 및 이전 레이어에서 수행되므로 비즈니스 관련 예외가 발생하지 않으며 Dao는 데이터베이스와 관련된 기본 예외를 차단합니다).
물론 이것은 개인적인 의견이며 정해진 공식은 없으며 앞서 말했듯이 유지 관리가 명확하고 쉽습니다.
1. 컨트롤러는 기본적으로 싱글톤이지만 @Scope(value = "prototype")
으로 대체할 수 있습니다.2. 로그인하면 정수가 반환되고, 열거형을 직접 추가할 수 있습니다.
3. 로직은 서비스 계층에서 처리된다고 규정되어 있습니다. 코드 중복성이 낮고 최적화가 더 좋습니다.
사람마다 의견은 다를 수 있습니다. 개발에서 더 중요한 것은 무엇을 해야 하는가보다 최적화하고 중복성을 줄이는 것입니다. . .1. 컨트롤러는 가능한 한 비즈니스 로직을 설계해서는 안 되며, 상호 작용만 포함해야 합니다.
2. 서비스는 재사용 가능한 비즈니스 로직입니다.
3. 컨트롤러는 서비스의 상위 호출자입니다.
4. 값을 반환하고 Controller 레이어에서 판단한 후 원하는 해당 예외를 발생시킵니다.
물론 이는 현재의 접근 방식이므로 공유해 주세요. . .
내 기사를 읽을 수 있습니다.
AOP, MVC - CodeIgniter /a/11에 대한 봄 학습 및 반성...
로직을 서비스에 배치하는 것이 좋습니다. 현재 분산형 마이크로서비스 아키텍처를 작업 중입니다. 분할할 때 기본적으로 일부 인터페이스를 다시 생성했습니다. 사용해야 하는 앱을 컨트롤러에 배치하면 공유할 수 없습니다.
캡슐화된 객체가 컨트롤러에 있는지 아니면 서비스에 있는지는 상황에 따라 다릅니다. 저는 개인적으로 단순한 매개변수라면 컨트롤러에 캡슐화해도 괜찮다고 생각합니다. 이는 매우 중복되어 서비스의 다양성을 저하시킵니다. 두 번째 질문의 경우 컨트롤러의 왼쪽에서 판단하고 예외를 발생시키기 위해 열거형 또는 다른 상태 코드를 사용할 수 없습니다. 프로젝트는 서비스 오류 메시지와 오류 코드를 뷰 계층에 직접 반환하여 클라이언트가 이를 처리할 수 있도록 하는 비즈니스와 유사한 예외 처리 메커니즘을 목표로 했습니다. 상태 코드 및 오류 메시지에 대해