[SPRING] 봄과 빈혈 도메인 모델

봄과 빈혈 도메인 모델

그래서, 나는 Spring / Hibernate 스택 객체를 다음과 같이 패턴 화하는 경향이 있음을 알았다.

여기에있는 문제는 Foos에는 실제 로직이 없다는 것입니다. 예를 들어 Foo가 만료 될 때마다 이메일을 전송해야하는 경우 Foo.expire ()에 대한 호출이 없습니다. FooService.expireFoo (fooId)에 대한 호출이 있습니다. 이것은 여러 가지 이유 때문입니다.

이런 이유로, 스프링 도메인 객체는 기본적으로 검증 로직을 사용하여 구조화 된 구조로되어있는 경향이 있습니다. 아마 이것은 괜찮습니다. 어쩌면 웹 서비스가 절차상의 코드 일 수도 있습니다. 어쩌면 새로운 기능이 쓰여질 때마다 동일한 오래된 객체를 새로운 방식으로 다루는 새로운 서비스를 만드는 것이 허용 될 수 있습니다.

그러나 저는 이런 종류의 디자인에서 벗어나고 싶습니다. 그리고 저는 다른 Spring의 사용법에 대해 궁금합니다. 당신은로드 타임 직조와 같은 멋진 트릭과 싸우십니까? 다른 트릭이 있니? 절차 적이라고 생각하십니까?

해결법

1. ==============================

   1.Spring이 AOP를 사용하여 Hibernate 인스턴스 화 된 인스턴스에 서비스를 주입하도록 할 수있다. 또한 인터셉터를 사용하여 Hibernate가 동일한 작업을 수행하도록 할 수 있습니다.

   Spring이 AOP를 사용하여 Hibernate 인스턴스 화 된 인스턴스에 서비스를 주입하도록 할 수있다. 또한 인터셉터를 사용하여 Hibernate가 동일한 작업을 수행하도록 할 수 있습니다.

   http://www.jblewitt.com/blog/?p=129를 참조하십시오.

   "Foo가 트랜잭션 방식으로 여러 가지 작업을 수행하는 것을 성가 시게하는 것"에 관해서는 서비스 구현이 트랜잭션에 대해 알고 / 관리 할 것으로 기대하며 현재 도메인 모델 내에서 서비스 인터페이스를 사용하고 있다면 이제는 그렇지 않을 것입니다. 그래서 성가신.

   도메인 모델을 저장할시기를 결정하는 것은 그것이 무엇이며 무엇을하고 있는지에 달려 있다고 생각합니다.

   FWIW 나는 같은 종류의 빈혈 구조를 만들어내는 경향이 있지만, 나는 거기에 도달하고있다. 이제 나는 더 현명한 방법으로 그것을 할 수 있음을 안다.

2. ==============================

   2.응용 프로그램이 절차 적 코딩 원칙을 중심으로 설계된 것 같습니다. 이것만으로도 당신이하려는 모든 객체 지향 프로그래밍을 방해 할 수 있습니다.

   응용 프로그램이 절차 적 코딩 원칙을 중심으로 설계된 것 같습니다. 이것만으로도 당신이하려는 모든 객체 지향 프로그래밍을 방해 할 수 있습니다.

   Foo가 제어하는 ​​동작이 없을 수도 있습니다. 비즈니스 로직이 최소한이라면 도메인 모델 패턴을 사용하지 않아도됩니다. 때때로 트랜잭션 스크립트 패턴이 의미가 있습니다.

   그 논리가 성장하기 시작하면 문제가 발생합니다. 트랜잭션 스크립트를 도메인 모델로 리팩토링하는 것은 쉬운 일이 아니지만 확실히 어렵지는 않습니다. Foo를 둘러싼 수많은 논리가 있다면 도메인 모델 패턴으로 이동하는 것이 좋습니다. 캡슐화의 이점으로 인해 진행중인 작업과 무엇이 무엇과 관련되어 있는지 쉽게 이해할 수 있습니다.

   Foo.Expire ()를 원한다면 Foo 클래스에서 OnExpiration과 같은 이벤트를 생성하십시오. foo.OnExpiration + = FooService.ExpireFoo (foo.Id) 오브젝트 생성시, 아마도 FooRepository가 사용하는 팩토리를 통해 가능합니다.

   정말 먼저 생각해. 모든 것이 이미 올바른 위치에 있다는 것은 가능합니다 ... 지금은.

   행운을 빕니다!

3. ==============================

   3.나는 당신의 문제를 해결할 간단한 리팩토링 패턴이 있다고 생각한다.

   나는 당신의 문제를 해결할 간단한 리팩토링 패턴이 있다고 생각한다.

   이렇게하면 풍부한 도메인 모델로 나아갈 수 있습니다. 또한 모든 DB 의존 코드가 FooService 임 플러먼트에 남아 있고 FooService에서 Foo로 비즈니스 로직을 마이그레이션하는 데 도움이되므로 Single Responsibility Principle을 보존합니다. 백엔드를 다른 DB 또는 메모리 또는 모의 (테스트 용)로 전환하려면 FooService 레이어 이외의 다른 것을 변경할 필요가 없습니다.

   ^ FooService가 주어진 Foo와 속성 X를 공유하는 가장 최근의 Foo를 선택하는 것과 같이 ORM에서 너무 느린 DB 호출을한다고 가정합니다. 그게 내가 가장 많이 본 것입니다.

   예

   대신에:

   class Controller{
       public Response getBestStudentForSchool( Request req ){
           Student bestStudent = StudentService.findBestPupilForSchool( req.getParam( "schlId" ).asInt() );
           ...
       }
   }
   

   다음과 같이 움직일 것입니다 :

   class Controller{
       public Response getBestStudentForSchool( Request req ){
           School school = repo.get( School.class, req.getParam( "schlId" ).asInt() ); 
           Student bestStudent = school.getBestStudent();
           ...
       }
   }
   

   나는 당신이 이미 동의 할 것을 희망합니다. 이제 다른 데이터베이스 호출을하고 있지만 세션에서 캐시 된 학교를 계속 유지하면 벌금이 무시됩니다. 진정으로 OOP 모델은 사용하고있는 빈혈 모델보다 효율적이지는 않지만 코드 명확성을 통한 버그 감소는 그만한 가치가 있어야합니다. 언제나처럼, YMMV.

from https://stackoverflow.com/questions/1304245/spring-and-the-anemic-domain-model by cc-by-sa and MIT license