[SPRING] 자바 프레임 워크 전쟁 : 봄과 겨울잠

자바 프레임 워크 전쟁 : 봄과 겨울잠

개발자들이 내전을 벌이고 있습니다. 한 캠프에서 그들은 Hibernate와 Spring을 포용했습니다. 다른 캠프에서는 프레임 워크를 비난했습니다 - 그들은 최대 절전 모드를 고려하고 있습니다.

질문은 : 초보자 Hibernate-Spring 변환자가 비틀 거릴 가능성이있는 불쾌한 놀라움, 약점 또는 구덩이 - 낙오가 있습니까?

추신 : 우리는 매우 정교하지 않은 DAO 라이브러리를 가지고 있습니다. 나는 그것이 Hibernate의 풍부함을 의심하지만 어떤 종류의 완성도에 도달하고있다. (즉, 마지막 몇 가지 프로젝트에서는 변경되지 않았다.)

해결법

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

   1.나는 과거에 Hibernate를 여러 번 사용했다. 문법을 결정하는 것이 문서, Google 및 구버전을 통해 스 캐빈 져 (scavenger) 사냥으로 바뀌는 경우를 겪었습니다. 그것은 강력한 도구이지만 문서화가 잘되어 있지 않습니다 (마지막으로 보았습니다).

   나는 과거에 Hibernate를 여러 번 사용했다. 문법을 결정하는 것이 문서, Google 및 구버전을 통해 스 캐빈 져 (scavenger) 사냥으로 바뀌는 경우를 겪었습니다. 그것은 강력한 도구이지만 문서화가 잘되어 있지 않습니다 (마지막으로 보았습니다).

   봄에 관해서는, 지난 몇 년 동안 인터뷰했거나 보았던 거의 모든 직업은 봄과 관련이 있습니다. 사실 자바 / 웹의 사실상 표준이되었습니다. 이 도구를 사용하면 개발자가 향후 시장성을 높일 수 있으며 응용 프로그램을 이해할 수있는 많은 사람들이있을 때 도움이됩니다.

   자신 만의 프레임 워크를 작성하는 것은 유혹적이고 교육적이며 재미 있습니다. 결과가 그렇게 좋지는 않습니다.

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

   2.그들은 프레임 워크를 비난했습니다.

   그들은 프레임 워크를 비난했습니다.

   너트 야. 기성품 프레임 워크를 사용하지 않으면 자신 만의 프레임 워크를 만들 수 있습니다. 여전히 프레임 워크입니다.

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

   3.Hibernate는 확실한 단서를 가지고 있지만 해결하려고하는 문제가 복잡하기 때문에 그 것이다. 누군가 Hibernate에 대해 불평 할 때마다 나는 그것을 사용하지 않는다면 유지해야 할 지루한 DAO 코드를 상기시킨다.

   Hibernate는 확실한 단서를 가지고 있지만 해결하려고하는 문제가 복잡하기 때문에 그 것이다. 누군가 Hibernate에 대해 불평 할 때마다 나는 그것을 사용하지 않는다면 유지해야 할 지루한 DAO 코드를 상기시킨다.

   몇 가지 팁 :

4. ==============================

   4.꽤 복잡한 데이터베이스를 가지고 있다면, Hibernate는 당신을위한 것이 아닐 수도 있습니다. 직장에서 우리는 많은 데이터를 가진 매우 복잡한 데이터베이스를 가지고 있으며, Hibernate는 실제로 우리에게 적합하지 않습니다. 대신 iBATIS를 사용하기 시작했습니다. 그러나, 나는 Hibernate를 성공적으로 사용하는 많은 개발 상점을 알고있다. 그리고 그것은 당신을 위해 많은 일을한다. 그래서 고려할 가치가있다.

   꽤 복잡한 데이터베이스를 가지고 있다면, Hibernate는 당신을위한 것이 아닐 수도 있습니다. 직장에서 우리는 많은 데이터를 가진 매우 복잡한 데이터베이스를 가지고 있으며, Hibernate는 실제로 우리에게 적합하지 않습니다. 대신 iBATIS를 사용하기 시작했습니다. 그러나, 나는 Hibernate를 성공적으로 사용하는 많은 개발 상점을 알고있다. 그리고 그것은 당신을 위해 많은 일을한다. 그래서 고려할 가치가있다.

   Spring은 올바르게 사용하는 방법을 알고 있다면 좋은 도구입니다.

   나는 프레임 워크가 확실히 좋은 것임을 말할 것입니다 - 다른 사람들이 지적한 것처럼, 당신은 바퀴를 재발견하고 싶지 않습니다. Spring은 모듈을 많이 포함하고 있으므로 많은 코드를 작성할 필요가 없다. "여기 발명되지 않은"증후군에 굴복하지 마십시오!

5. ==============================

   5.Lazy 로딩은 지속성 프레임 워크를 위해 Hibernate를 사용하는 MVC 애플리케이션에서 큰 문제입니다. 컨트롤러에서 객체를로드하고이를 JSP 뷰에 전달합니다. Hibernate 세션은 컨트롤러가 완료 될 때 닫혀 있기 때문에 클래스의 멤버 일부 또는 전부가 프록시되고 모든 것이 폭발합니다.

   Lazy 로딩은 지속성 프레임 워크를 위해 Hibernate를 사용하는 MVC 애플리케이션에서 큰 문제입니다. 컨트롤러에서 객체를로드하고이를 JSP 뷰에 전달합니다. Hibernate 세션은 컨트롤러가 완료 될 때 닫혀 있기 때문에 클래스의 멤버 일부 또는 전부가 프록시되고 모든 것이 폭발합니다.

   문제를 이해하고 해결책을 얻으려면 View Session의 Open Session 글을 읽어야합니다. Spring을 사용하고 있다면이 블로그 기사는 뷰 문제에서 열린 세션에 대한 Spring 솔루션을 설명합니다.

6. ==============================

   6.이것은 내가 Hibernate 시대에 빠졌던 한 가지입니다 (기억할 수 있습니다). Hibernate는 (부모 엔티티에있는) 콜렉션으로부터 (여러개의) 자식 객체를 삭제 한 다음, 중간에 플러시하지 않고 동일한 엔티티에 같은 엔티티를 추가 할 때, Hibernate는 "삭제"전에 "insert"를 수행 할 것이다. 하위 테이블에 해당 열 중 하나에서 고유 한 제약 조건이 있고 이전에 일부 데이터를 삭제 한 이후로 위반하지 않을 것으로 예상하는 경우 (나처럼) 좌절 할 준비를하십시오. 최대 절전 모드 포럼에서 제안하는 내용 :

   이것은 내가 Hibernate 시대에 빠졌던 한 가지입니다 (기억할 수 있습니다). Hibernate는 (부모 엔티티에있는) 콜렉션으로부터 (여러개의) 자식 객체를 삭제 한 다음, 중간에 플러시하지 않고 동일한 엔티티에 같은 엔티티를 추가 할 때, Hibernate는 "삭제"전에 "insert"를 수행 할 것이다. 하위 테이블에 해당 열 중 하나에서 고유 한 제약 조건이 있고 이전에 일부 데이터를 삭제 한 이후로 위반하지 않을 것으로 예상하는 경우 (나처럼) 좌절 할 준비를하십시오. 최대 절전 모드 포럼에서 제안하는 내용 :

   나는 둘 다 할 수 없었고 결국 Hibernate 소스를 조정하고 다시 컴파일했다. 단 한 줄의 코드였습니다. 그러나 그 한 줄을 찾는 노력은 약 27 잔의 커피와 3 개의 잠못드는 밤과 같았다.

   이것은 당신의 팀 (전문가 : Hibernate의 철학과 내부 작업에 대한 충분한 지식을 가진 사람)에 대한 진정한 전문가없이 Hibernate를 사용할 때 끝날지 모를 문제와 단점의 한 예일뿐입니다. 문제, 해결책, 커피 1 리터 및 불면의 밤 수는 다를 수 있습니다. 그러나 당신은 아이디어를 얻습니다.

7. ==============================

   7.Java로 많은 일을하지는 못했지만 많은 Java 개발자 그룹에서 일했습니다. 내가 가진 인상은 봄이 괜찮다는 것이 었습니다. 그러나 모두는 최대 절전 모드로 화가났다. 팀의 절반이 "만약 당신이 한 가지를 바꿀 수 있다면, 당신은 무엇을 바꿀 것입니까?" 그들은 "Hibernate를 없애라."라고 말할 것입니다. 내가 Hibernate를 배우기 시작했을 때 놀라 울 정도로 복잡하게 느껴졌지 만, 복잡성이 정당화되었는지 아닌지 (아마도 복잡한 문제를 해결할 필요가 있는지) 알기에는 충분히 배웠습니다.

   Java로 많은 일을하지는 못했지만 많은 Java 개발자 그룹에서 일했습니다. 내가 가진 인상은 봄이 괜찮다는 것이 었습니다. 그러나 모두는 최대 절전 모드로 화가났다. 팀의 절반이 "만약 당신이 한 가지를 바꿀 수 있다면, 당신은 무엇을 바꿀 것입니까?" 그들은 "Hibernate를 없애라."라고 말할 것입니다. 내가 Hibernate를 배우기 시작했을 때 놀라 울 정도로 복잡하게 느껴졌지 만, 복잡성이 정당화되었는지 아닌지 (아마도 복잡한 문제를 해결할 필요가 있는지) 알기에는 충분히 배웠습니다.

   팀은 Guice에 찬성하여 Spring을 제거했지만 최소한 내 관점과 다른 개발자들과의 정치적 변화와 같았습니다.

8. ==============================

   8.나는 항상 Hibernate가 약간 복잡하고 배우기가 어렵다는 것을 발견했다. 하지만 JPA (Java Persistence API)와 EJB (Enterprise Java Beans) 3.0이 존재하면서 잠시 동안은 JavaDoc 또는 XML을 통해 매핑을 생성하기 위해 클래스에 주석을 달기를 선호합니다. 최대 절전 모드에서 지원을 확인하십시오. 추가 보너스는 필요한 경우 나중에 데이터베이스 프레임 워크를 변경하는 것이 가능하지만 손쉽게는 안된다는 것입니다. OpenJPA를 사용하여 훌륭한 결과를 얻었습니다.

   나는 항상 Hibernate가 약간 복잡하고 배우기가 어렵다는 것을 발견했다. 하지만 JPA (Java Persistence API)와 EJB (Enterprise Java Beans) 3.0이 존재하면서 잠시 동안은 JavaDoc 또는 XML을 통해 매핑을 생성하기 위해 클래스에 주석을 달기를 선호합니다. 최대 절전 모드에서 지원을 확인하십시오. 추가 보너스는 필요한 경우 나중에 데이터베이스 프레임 워크를 변경하는 것이 가능하지만 손쉽게는 안된다는 것입니다. OpenJPA를 사용하여 훌륭한 결과를 얻었습니다.

   요즘 저는 JCR (Java Content Repository)을 점점 더 많이 사용하고 있습니다. 내 모듈이 단일 데이터 저장소를 공유 할 수있는 방식과 구조와 속성을 발전시킬 수있는 방법을 좋아합니다. 객체와 데이터베이스를 매핑하는 것이 노드와 속성을 사용하는 것이 훨씬 쉽다는 것을 알게되었습니다. 좋은 구현은 Jackrabbit입니다.

   Spring의 경우, 내가 좋아하는 기능이 많지만 XML을 구성하는 데 필요한 양은 결코 사용하지 않을 것임을 의미합니다. 대신 Guice를 활용하고 절대적으로 좋아합니다.

   검거하려면, 나는 당신의 의심스러운 개발자들에게 Hibernate가 그들의 삶을 어떻게 더 쉽게 만들 것인지를 보여줄 것이다. 봄에 관해서는 Guice가 실행 가능한 대안인지 심각하게 확인한 다음 Spring / Guice가 어떻게 개발을 더 쉽고 편하게하는지 보여 주려고합니다.

9. ==============================

   9.나는 많은 Spring / Hibernate 개발을 해왔다. 시간이 지남에 따라 사람들이 두 가지 방법을 함께 사용하는 방식이 조금 바뀌 었습니다. 원래의 HibernateTemplate 접근법은 그렇지 않으면 유용한 예외를 삼키고 감싸기 때문에 디버그하기 어렵다는 것이 판명되었다. 직접 Hiberante API에 문의하십시오!

   나는 많은 Spring / Hibernate 개발을 해왔다. 시간이 지남에 따라 사람들이 두 가지 방법을 함께 사용하는 방식이 조금 바뀌 었습니다. 원래의 HibernateTemplate 접근법은 그렇지 않으면 유용한 예외를 삼키고 감싸기 때문에 디버그하기 어렵다는 것이 판명되었다. 직접 Hiberante API에 문의하십시오!

   생성 된 SQL을 계속 살펴보십시오 (SQL을 표시하도록 개발 로깅을 구성하십시오). 데이터베이스에 추상화 계층이 있다고해서 더 이상 SQL로 생각할 필요가 없다는 것을 의미하지는 않습니다. 그렇지 않으면 좋은 성과를 얻지 못할 것입니다.

   프로젝트를 고려하십시오. 필자는 엄격한 성능 요구 사항, 복잡한 레거시 스키마 또는 우수한 DBA가 우수한 SQL을 작성할 수있는 여러 경우에 최대 절전 모드에서 iBatis를 선택했습니다.

10. ==============================

    10.Hibernate에 관해서는 : 빠르게 변화하는 데이터베이스 스키마, 많은 양의 테이블을 다루는 애플리케이션을위한 아주 훌륭한 도구는 많은 간단한 CRUD 연산을 수행한다. 복잡 한 쿼리가 포함 된 보고서는 비교적 잘 처리되지 않습니다. 그러나이 경우에는 JDBC 또는 네이티브 쿼리에서 혼합하는 것을 선호합니다. 그래서 짧은 대답을 위해 : 나는 Hibernate를 배우는 데 드는 시간이 좋은 투자라고 생각한다. (그들은 EJB3.0과 JPA 표준에도 부합한다고 말하지만, 개인적으로 그것을 평가할 때 방정식에 들어 가지 않았다. 용도).

    Hibernate에 관해서는 : 빠르게 변화하는 데이터베이스 스키마, 많은 양의 테이블을 다루는 애플리케이션을위한 아주 훌륭한 도구는 많은 간단한 CRUD 연산을 수행한다. 복잡 한 쿼리가 포함 된 보고서는 비교적 잘 처리되지 않습니다. 그러나이 경우에는 JDBC 또는 네이티브 쿼리에서 혼합하는 것을 선호합니다. 그래서 짧은 대답을 위해 : 나는 Hibernate를 배우는 데 드는 시간이 좋은 투자라고 생각한다. (그들은 EJB3.0과 JPA 표준에도 부합한다고 말하지만, 개인적으로 그것을 평가할 때 방정식에 들어 가지 않았다. 용도).

    봄에 관해서는 ... 담즙 블로그를 참조하십시오 :)

    기억하십시오 : 프레임 워크는 은색 탄환이 아니지만 바퀴를 재발 명하면 안됩니다.

11. ==============================

    11.Hibernate와 같은 잘 알려진 프레임 워크를 사용하면 코드가 특정 곰팡이 또는 사고 방식에 맞기 때문에 실제로 도움이된다는 것을 알았습니다. 의미, 당신이 Hibernate를 사용하고 있기 때문에, 당신은 코드를 특정 방식으로 작성하고, 대부분의 경우 Hibernate를 아는 모든 개발자들이 당신의 사고 방식을 아주 쉽게 따라갈 수 있습니다.

    Hibernate와 같은 잘 알려진 프레임 워크를 사용하면 코드가 특정 곰팡이 또는 사고 방식에 맞기 때문에 실제로 도움이된다는 것을 알았습니다. 의미, 당신이 Hibernate를 사용하고 있기 때문에, 당신은 코드를 특정 방식으로 작성하고, 대부분의 경우 Hibernate를 아는 모든 개발자들이 당신의 사고 방식을 아주 쉽게 따라갈 수 있습니다.

    물론 여기에는 단점이 있습니다. 최대 절전 모드 개발자가되기 전에 원형 구멍에 사각형을 맞추려고한다는 것을 알게 될 것입니다. 당신은 Hibernate가 그림에 들어 오기 전에 당신이하고 싶은 일을 알고 있고, Hibernate가 그 일을하기 전에 어떻게해야했는지를 알았지 만, 그 일을하는 최대 절전 모드를 찾는 것은 꽤 시간이 걸린다.

    여전히 컨설턴트를 자주 고용하는 회사 (짧은 시간에 많은 소스 코드를 이해해야하는 개발자) 또는 개발자가 자주 서명하거나 종료하는 곳, 또는 핵심 개발자가 영원히 있고 일을 결코 바꿀 수 없다 - Hibernate와 다른 표준 프레임 워크는 내가 생각하기에 꽤 좋은 생각이다.

    /에이스

12. ==============================

    12.Spring과 Hibernate는 마스터하기에 까다로운 프레임 워크입니다. 프레임 워크를 파악하는 동안 마감 시간이 긴 프로젝트에서 사용하는 것은 좋지 않을 수 있습니다.

    Spring과 Hibernate는 마스터하기에 까다로운 프레임 워크입니다. 프레임 워크를 파악하는 동안 마감 시간이 긴 프로젝트에서 사용하는 것은 좋지 않을 수 있습니다.

    프레임 워크의 이점은 기본적으로 일관된 코드를 제품으로 사용할 수있는 플랫폼을 제공하는 것입니다. 경험을 토대로 개발자가 프레임 워크 모범 사례에서 프레임 워크 설정을 경험하도록하는 것이 좋습니다.

    응용 프로그램 및 / 또는 데이터베이스의 디자인에 따라 프레임 워크가 성능을 저해하지 않도록하기 위해 우회해야하는 단점도 있습니다.

13. ==============================

    13.제 견해로, Spring의 가장 큰 장점은 더 나은 개발 방법, 특히 느슨한 결합, 테스트 및 더 많은 인터페이스를 장려하고 가능하게한다는 것입니다. Spring이없는 Hibernate는 실제로 고통 스러울 수 있지만, 둘은 매우 유용합니다.

    제 견해로, Spring의 가장 큰 장점은 더 나은 개발 방법, 특히 느슨한 결합, 테스트 및 더 많은 인터페이스를 장려하고 가능하게한다는 것입니다. Spring이없는 Hibernate는 실제로 고통 스러울 수 있지만, 둘은 매우 유용합니다.

    기존 프로젝트를 어떤 프레임 워크로 개조하는 것은 어려울 수 있지만 리팩토링 프로세스는 종종 장기 유지 관리에 심각한 이점을줍니다.

14. ==============================

    14.나는 이것에 관한 많은 게시물에 동의해야한다. 나는 둘 다 다양한 설정에서 광범위하게 사용 해왔다. 디자인 결정을 취소 할 수 있다면 Hibernate를 사용했을 것입니다. 우리는 실제로 iBatis와 Spring-JDBC를위한 Hibernate를 세계 최고의 접근 방식으로 바꾸기 위해 우리 제품 중 하나의 릴리스를 예산 책정했습니다. 새로운 개발자가 Spring-JDBC, Spring-MVC, Spring-Ioc 및 iBatis를 사용하여 최대 절전 모드로 작업 할 때보 다 더 빠르게 속도를 높일 수 있습니다.

    나는 이것에 관한 많은 게시물에 동의해야한다. 나는 둘 다 다양한 설정에서 광범위하게 사용 해왔다. 디자인 결정을 취소 할 수 있다면 Hibernate를 사용했을 것입니다. 우리는 실제로 iBatis와 Spring-JDBC를위한 Hibernate를 세계 최고의 접근 방식으로 바꾸기 위해 우리 제품 중 하나의 릴리스를 예산 책정했습니다. 새로운 개발자가 Spring-JDBC, Spring-MVC, Spring-Ioc 및 iBatis를 사용하여 최대 절전 모드로 작업 할 때보 다 더 빠르게 속도를 높일 수 있습니다.

    Hibernate는이 KISS 개발자에게는 너무 복잡합니다. DBA가 생성 된 SQL을 데이터베이스가보고 최적의 버전으로 되돌려 보내는 경우 하늘이 최대 절전 모드로 전환하도록 도와줍니다.

15. ==============================

    15.가장 큰 답변은 Hibernate가 문서화가 잘되어 있지 않다는 것을 언급한다. 나는 온라인 레퍼런스 매뉴얼이 더 완전 할 수 있다는 것에 동의한다. 그러나, Hibernate의 저자 인 'Hibernate로 자바 영속성'에 의해 쓰여진 책은 모든 Hibernate 사용자를 위해 꼭 읽어야하고 매우 완벽합니다.

    가장 큰 답변은 Hibernate가 문서화가 잘되어 있지 않다는 것을 언급한다. 나는 온라인 레퍼런스 매뉴얼이 더 완전 할 수 있다는 것에 동의한다. 그러나, Hibernate의 저자 인 'Hibernate로 자바 영속성'에 의해 쓰여진 책은 모든 Hibernate 사용자를 위해 꼭 읽어야하고 매우 완벽합니다.

16. ==============================

    16.@ 슬림 - 오늘 아침에 다시 너와 함께있다.

    @ 슬림 - 오늘 아침에 다시 너와 함께있다.

    그것은 여기에 발명되지 않은 증후군의 고전적인 사례처럼 들립니다. 그들이 봄에 예민하지 않다면, 그들은 자신의 틀을 굴리는 것 (그들이 그것을하는지 아닌지)에 관계없이 다른 선택을 고려해야한다. Guice는 가능성을 염두에두고 있습니다. 또한 picocontainer. 당신이 필요로하는 것에 따라 다른 것들이 있습니다.

17. ==============================

    17.Spring과 Hibernate는 확실히 인생을 편하게 해줍니다. 처음 시작하는 데는 시간이 많이 걸리지 만 나중에는 그 혜택을 누리게 될 것입니다. XML이 주석으로 대체되면서 수백 줄의 XML을 입력 할 필요가 없습니다.

    Spring과 Hibernate는 확실히 인생을 편하게 해줍니다. 처음 시작하는 데는 시간이 많이 걸리지 만 나중에는 그 혜택을 누리게 될 것입니다. XML이 주석으로 대체되면서 수백 줄의 XML을 입력 할 필요가 없습니다.

    AppFuse는 학습 곡선을 줄이기 위해 고려해야 할 사항입니다. 애플리케이션을 생성하고 연구하고 적용하며 벗어나십시오.

18. ==============================

    18.틀은 사악하지 않습니다. Java SDK조차 프레임 워크입니다.

    틀은 사악하지 않습니다. Java SDK조차 프레임 워크입니다.

    그들이 싸우는 것은 프레임 워크 확산입니다. 프로젝트를 시작하기 위해 프레임 워크를 프로젝트에 가져 가면 안됩니다. 합리적인 시간에 일관된 가치를 가져와야합니다. 모든 프레임 워크는 학습 곡선을 필요로하지만 나중에 생산성 및 기능 향상으로 보상해야합니다.

    일관성없는 데이터베이스 사용, 복잡한 캐시 메커니즘 또는 수많은 다른 이유로 인해 디버깅하기 어려운 코드로 고생하는 경우. Hibernate는 큰 가치를 추가 할 것이다. 학습 곡선 (제게는 약 1 개월의 실용적인 업무 시간)을 제외하고는 당신에게 기본을 설명 할 사람이 있다면 함정은 없었습니다.

from https://stackoverflow.com/questions/100243/java-frameworks-war-spring-and-hibernate by cc-by-sa and MIT license