java - 模型关联太多，如何分离做到单一化

Answer 1

오랫동안 ORM 이용을 중단하신 분들께 드디어 불만과 의견을 표명할 수 있게 되었습니다.

Java 백엔드를 작성하는 사람들이 모델 객체를 많이 작성하는 것을 종종 볼 수 있으며, @chanjarster가 말했듯이 일대일, 일대다, 다대다 등 다양한 상속과 조합이 사용됩니다. -다수, 단일 및 양방향, 직접적으로 혼동됨...

사실 개인적으로 ORM는 정말 나쁜 발명품이라고 생각해요. ORM의 유일한 장점은 SQL을 생각할 필요가 없다는 점이에요. . 이제 대부분의 SQL 프로그램에서 Java을 작성하는 것은 여기서 다양한 객체 매핑 규칙을 암기하는 것보다 훨씬 간단합니다...SQL

ORM의 단점을 정리해보세요

1. 성숙한 프레임워크를 사용하더라도 성능은 높지 않습니다. 때로는 속성에 액세스하고 전체 개체의 데이터를 로드하면 됩니다. (PS: 구성이 가능하지만 학습 비용도 높습니다.)

2. 융통성이 부족합니다. 많은 비즈니스 요구사항에는 테이블 조회, 함수 호출, 저장 프로시저가 필요합니다...

3. 추상이 너무 귀찮아서 헷갈렸어요

결론적으로 동의한다면 포기하세요

ORM

대안:

1. MyBaits를 유연하게 제어하려면 SQL을 사용하여

   을 직접 작성하세요.

2. 데이터베이스를 사용하여 객체를 NOSQLJSONMongoDb과 같이 직접 저장할 수 있는

   데이터로 변환합니다.

Answer 2

질문이 너무 크네요. 간단히 말해서 모델과 모델의 관계를 입체적으로 파악하는 것입니다

1. "참조 관계" 또는 "소유 관계". A가 B를 소유한 경우 A가 삭제되면 B도 삭제됩니다. A가 B를 참조하는 경우 A가 B를 삭제하면 삭제할 필요가 없습니다. 이는 사업에 따라 다릅니다.

2. 단방향 또는 양방향. 이는 비즈니스에 따라 다르며 스스로 판단할 수 있지만 "참조 관계"에서 한 가지를 기억하십시오. 단방향을 유지하십시오. "소유 관계"에서 양방향성은 괜찮습니다.

3. 일대일, 일대다, 다대일, 다대다. 이에 대해 자세히 설명하지는 않겠지만 한 가지 주의할 점은 다대다 방식을 피하는 것입니다. 다대다 방식을 사용하는 경우 반드시 이렇게 해야 하는지 스스로에게 물어보세요.

방법론에 대해 꼭 물어봐야 한다면 DDD(Domain Driven Design)의 Aggregate Root 개념을 살펴보세요.