젠드 프레임 워크 및 Doctrine 2을 통합 중이며 서비스 레이어을 발견했습니다.ZF + Doctrine 2 : 중형 모델 클래스 또는 경량 모델 + 서비스 계층?
지금은 이해 (내가 잘못?) 나는이 가능한 아키텍처를 가지고 :
각 장단점은 무엇입니까?
도메인 논리를 모델 외부에 배치하여 OOP를 잃는 것이 이상한 것처럼 보이므로 서비스 레이어를 사용하는 이유를 이해할 수 없습니다.
귀하의 서비스 계층이 외부 모델로 생각되는 이유는 무엇입니까? 그렇지 않습니다. 실제로 모델, 엔티티, 리포지토리 등과 함께 모델의 핵심 부분입니다.
Doctine2를 사용하는 경우 서비스 계층이 필요합니다. 한 가지 이유는 엔티티가 EntityManager에 대해 알지 못하기 때문입니다 (테스트 가능성이 손상됨). 또 하나는 컨트롤러가 EM을 구동하는 것을 원하지 않는다는 것입니다 (컨트롤러의 작업이 지속성에 대해 아는 것이 아닙니다).
일반적으로 서비스 계층이 모델에 대한 컨트롤러의 인터페이스 인 아키텍처를 사용합니다. 서비스 계층은 엔터티에서 작동하는 함수를 노출합니다 (매개 변수로 반환하거나 반환하거나 둘 다). 엔터티의 지속성은 서비스 계층에 의해 숨겨집니다. 서비스 클래스가 EM과 저장소를 구동하거나 컨트롤러가 결코 알 수없는 다른 코드에 위임합니다.
그래서 서비스 계층은 컨트롤러가 비즈니스 데이터를 조작하는 데 사용할 수있는 API를 제공합니다.
왜 OOP를 풀어 놓았는지 이해하는 데는 어려움이 있습니다 만, 대단하고 명확한 답변 감사합니다. 나는 $ user-> generatePassword()가 메소드가 사용자에게 적용되기 때문에'$ userService-> generatePassword ($ user)'는 매개 변수에 적용된 "함수"가 아닙니다 ... 그것은 "외부"가 의미하는 것입니다. 나에게 그것은 OOP (객체와 객체의 메소드)와 함수 프로그래밍의 차이점과 비슷하다. 서비스 계층에서 객체는 단지 데이터 컨테이너 일뿐입니다. –
@matthieu'generatedPassword()'메소드가 임의의 문자열을 생성하는 경우, Entity에서 해당 메소드를 사용하는 것이 좋습니다. 어떤 외부 적, 지속성 관련 의존성도 제기하지 않습니다. – Cobby
@matthieu - 엔티티의 *는 * 데이터 컨테이너입니다 (내부 상태를 조작하거나보고 할 수있는 메서드가 있기 때문에) 단지 "멋진"것입니다. generatePassword()는 괜찮을 수도 있습니다. 단, 외부적인 것에 의존하지 않는 한. 예를 들어, generatePassword()가 8 개의 임의의 문자를 생성하고 해당 문자열을 $ this-> password에 할당하면 (또는 $ this-> setPassword()로 전달하여 적절하게 해시하는 경우) 괜찮습니다. 그것은 단지 사용자의 암호에만 영향을 미치기 때문에 괜찮습니다. 이제 사용자에게 새 비밀번호를 전자 메일로 보내려면 다른 곳의 – timdev
항상 2 가지 아키텍처가 가능합니다. – Fatmuemoo