자바 프레임워크 전쟁:봄과 최대 절전 모드
https://stackoverflow.com/questions/100243
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
내 개발자들은 내전을 벌이고 있습니다.한 캠프에서는 Hibernate와 Spring을 수용했습니다.다른 쪽에서는 프레임워크를 비난했지만 Hibernate를 고려하고 있습니다.
질문은 ~이야:초보자 Hibernate-Spring 전환자가 우연히 발견할 수 있는 불쾌한 놀라움, 약점 또는 함정이 있습니까?
추신:우리는 그다지 정교하지 않은 DAO 라이브러리를 가지고 있습니다.나는 그것이 Hibernate의 풍부함을 가지고 있는지 의심스럽습니다. 그러나 그것은 일종의 성숙에 도달하고 있습니다(예:포함된 지난 몇 개의 프로젝트에서는 변경되지 않았습니다.
해결책
나는 과거에 Hibernate를 여러 번 사용해왔습니다.매번 문서, Google 및 이전 버전을 통해 구문을 찾아 헤매는 구문 결정이 필요한 극단적인 사례를 접했습니다.이는 강력한 도구이지만 문서화 수준이 낮습니다(마지막으로 살펴봤습니다).
Spring의 경우 지난 몇 년간 제가 인터뷰했거나 살펴본 거의 모든 직업이 Spring과 관련되어 있었고 사실상 Java/웹의 표준이 되었습니다.이를 사용하면 개발자가 향후 시장성을 더욱 높일 수 있으며, 애플리케이션을 이해하는 사람들이 많아지므로 도움이 될 것입니다.
자신만의 프레임워크를 작성하는 것은 매력적이고 교육적이며 재미있습니다.결과가 별로 좋지 않습니다.
다른 팁
그들은 비난했습니다 프레임워크?
그건 말도 안되는 소리입니다.기성 프레임워크를 사용하지 않는 경우 자체 프레임워크를 만듭니다.아직은 프레임워크입니다.
Hibernate에는 확실히 특이한 점이 있지만 그것은 해결하려는 문제가 복잡하기 때문입니다.누군가가 Hibernate에 대해 불평할 때마다 나는 그들이 그것을 사용하지 않는다면 유지해야 할 모든 지루한 DAO 코드를 상기시켜 줍니다.
몇 가지 팁:
- Hibernate는 좋은 데이터베이스 디자인을 대체할 수 없습니다.Hibernate 스키마는 괜찮지만 가끔 수정해야 할 것입니다
- 결국 당신은 Hibernate가 클래스를 게으르게 로드하는 방법과 그것이 사물에 어떤 영향을 미치는지 이해해야 할 것입니다.Hibernate는 Java 바이트코드를 수정하며 객체 링크가 null인 이유를 설명하기 위해서만 조만간 깊이 파고들어야 할 것입니다.
- 가능하다면 주석을 사용하세요.
- 시간을 내어 Hibernate 성능 조정 기술을 배우십시오. 그러면 장기적으로 여러분의 시간을 절약해 줄 것입니다.
상당히 복잡한 데이터베이스를 가지고 있다면 Hibernate가 적합하지 않을 수 있습니다.직장에서 우리는 많은 데이터를 포함하는 상당히 복잡한 데이터베이스를 가지고 있으며 Hibernate는 실제로 우리에게 작동하지 않습니다.대신 iBATIS를 사용하기 시작했습니다.그러나 나는 Hibernate를 성공적으로 사용하는 많은 개발 회사를 알고 있습니다. 그리고 그것은 당신을 위해 많은 힘든 작업을 수행합니다. 따라서 고려해 볼 가치가 있습니다.
Spring은 올바르게 사용하는 방법을 안다면 좋은 도구입니다.
나는 프레임워크가 확실히 좋은 것이라고 말하고 싶습니다. 다른 사람들이 지적했듯이 바퀴를 재발명하고 싶지는 않습니다.Spring에는 많은 모듈이 포함되어 있으므로 많은 코드를 작성할 필요가 없습니다."여기에서 발명되지 않은 것" 증후군에 굴복하지 마십시오!
지연 로딩은 지속성 프레임워크를 위해 Hibernate를 사용하는 MVC 애플리케이션의 가장 큰 문제입니다.컨트롤러에 객체를 로드하고 이를 JSP 보기에 전달합니다.컨트롤러가 완료될 때 Hibernate 세션이 닫히기 때문에 클래스 멤버 중 일부 또는 전부가 프록시되고 모든 것이 폭발합니다.
당신은 읽어야 할 것입니다 보기에서 세션 열기 문제를 이해하고 해결책을 얻기 위한 기사입니다.Spring을 사용한다면 this 블로그 기사 보기 문제에서 열린 세션에 대한 Spring 솔루션을 설명합니다.
이것은 내가 최대 절전 모드 시절에 빠졌던 것 중 하나입니다.컬렉션(부모 엔터티에 있는)에서 (여러) 하위 개체를 삭제한 다음 중간에 플러시하지 않고 한 트랜잭션에서 동일한 컬렉션에 새 엔터티를 추가하면 Hibernate는 "삭제" 전에 "삽입"을 수행합니다.하위 테이블의 열 중 하나에 고유 제약 조건이 있고 이전에 이미 일부 데이터를 삭제했기 때문에 이를 위반하지 않을 것이라고 예상하는 경우(나처럼) 실망할 준비를 하십시오.Hibernate 포럼에서는 다음을 제안합니다.
- DB 설계 결함, 재설계였습니다.
- 삭제와 삽입 사이에 플러시(또는 원할 경우 커밋)합니다.
나는 둘 다 할 수 없었고 결국 Hibernate 소스를 조정하고 다시 컴파일하게 되었습니다.단 한 줄의 코드였습니다.그러나 한 줄이 약 27잔의 커피와 3일간의 잠 못 이루는 밤과 같다는 것을 알아내려는 노력.
이것은 팀에 실제 전문가가 없이 Hibernate를 사용할 때 발생할 수 있는 문제와 기이함의 한 예일 뿐입니다(전문가:Hibernate의 철학과 내부 작동에 대한 적절한 지식을 가진 사람).귀하의 문제, 해결책, 커피 리터, 잠 못 이루는 밤 수는 다를 수 있습니다.하지만 당신은 아이디어를 얻습니다.
저는 Java를 많이 다루지는 않았지만 대규모 Java 개발자 그룹에서 일했습니다.내가 받은 인상은 봄이 괜찮다는 것이었습니다.그러나 모두가 Hibernate에서 화를 냈습니다.팀의 절반은 "한 가지를 바꿀 수 있다면 무엇을 바꾸겠습니까?" 그리고 그들은 "최대 절전 모드를 제거하십시오."라고 말할 것입니다.내가 Hibernate를 배우기 시작했을 때 나는 놀라울 정도로 복잡하다는 사실에 놀랐지만, 그 복잡성이 정당한지 아닌지(어쩌면 일부 복잡한 문제를 해결하는 데 필요할 수도 있음)를 알기에는 충분히 배우지 못했습니다(고맙게도 계속 진행했습니다).
팀은 Guice를 선호하여 Spring을 제거했지만 적어도 나와 대화한 다른 개발자의 관점에서는 정치적 변화에 더 가깝습니다.
나는 항상 Hibernate가 약간 복잡하고 배우기 어렵다는 것을 알았습니다.그러나 ~함에 따라 JPA (Java 지속성 API) 및 EJB (Enterprise Java Beans) 3.0이 나온 지 꽤 되었지만, 저는 JavaDoc이나 XML을 통해 매핑을 생성하기 위해 클래스에 주석을 추가하는 것을 더 선호합니다.확인해 보세요 최대 절전 모드에서 지원.추가 보너스는 필요한 경우 나중에 데이터베이스 프레임워크를 변경할 수 있다는 것입니다(쉽지는 않지만).나는 사용했다 오픈JPA 좋은 결과로.
최근에 나는 사용하고있다 JCR (Java 콘텐츠 저장소) 점점 더 많아지고 있습니다.저는 모듈이 단일 데이터 저장소를 공유하고 구조와 속성을 발전시킬 수 있는 방식을 좋아합니다.내 개체를 데이터베이스에 매핑하는 것보다 노드 및 속성을 사용하여 작업하는 것이 훨씬 쉽다는 것을 알았습니다.좋은 구현은 잭래빗.
Spring의 경우 내가 좋아하는 기능이 많이 있지만 구성하는 데 필요한 XML의 양 때문에 나는 결코 사용하지 않을 것입니다.대신 나는 활용한다 기이스 정말 좋아해요.
정리하자면, 나는 Hibernate가 그들의 삶을 어떻게 더 쉽게 만들어 줄지 의심하는 개발자들에게 보여주고 싶습니다.Spring에 관해서는 Guice가 실행 가능한 대안인지 진지하게 확인한 다음 Spring/Guice가 어떻게 개발을 더 좋고 쉽게 만드는지 보여주려고 노력할 것입니다.
저는 Spring/Hibernate 개발을 많이 해왔습니다.시간이 지남에 따라 사람들이 두 가지를 조합하여 사용하는 방식이 약간 변경되었습니다.원래의 HibernateTemplate 접근 방식은 유용한 예외를 삼키고 래핑하기 때문에 디버깅하기 어려운 것으로 입증되었습니다.Hiberante API와 직접 대화해보세요!
생성된 SQL을 계속 살펴보세요(SQL을 표시하도록 개발 로깅을 구성하세요).데이터베이스에 대한 추상화 계층이 있다고 해서 더 이상 SQL로 생각할 필요가 없다는 의미는 아닙니다.그렇지 않으면 좋은 성능을 얻을 수 없습니다.
프로젝트를 고려하십시오.나는 엄격한 성능 요구 사항, 복잡한 레거시 스키마 또는 탁월한 SQL을 작성할 수 있는 훌륭한 DBA가 있는 여러 경우에 Hibernate 대신 iBatis를 선택했습니다.
최대 절전 모드의 경우:빠르게 변화하는 데이터베이스 스키마, 많은 양의 테이블을 처리하고 많은 간단한 CRUD 작업을 수행하는 매우 유용한 응용 프로그램 도구입니다.복잡한 쿼리가 포함된 보고서는 잘 처리되지 않습니다.그러나 이러한 경우에는 JDBC 또는 기본 쿼리를 혼합하는 것을 선호합니다.따라서 짧은 답변을 드리자면 다음과 같습니다.나는 Hibernate를 배우는 데 시간을 투자한 것이 좋은 투자라고 생각합니다(EJB3.0 및 JPA 표준도 준수한다고 말하지만 개인적인 용도로 평가할 때 그것은 방정식에 포함되지 않았습니다).
봄의 경우...보다 담즙 블로그 :)
나는 Hibernate와 같은 잘 알려진 프레임워크를 사용하는 것이 당신의 코드를 특정 틀이나 사고 방식에 맞추기 때문에 정말 도움이 된다고 생각합니다.즉, 당신은 Hibernate를 사용하고 있기 때문에 특정한 방식으로 코드를 작성하고, Hibernate를 아는 모든 개발자는 아니지만 대부분이 당신의 사고 방식을 아주 쉽게 따를 수 있을 것입니다.
물론 여기에는 단점이 있습니다.당신이 Hibernate 개발자의 전문가가 되기 전에 당신은 원형 구멍에 정사각형을 맞추려고 노력하고 있다는 것을 알게 될 것입니다.당신은 당신이 무엇을 하고 싶은지, 그리고 Hibernate가 등장하기 전에 그것을 어떻게 해야 하는지 알고 있지만, 그것을 하는 Hibernate 방식을 찾는 데는 시간이 걸릴 수도 있습니다...시간이 꽤 많아요.
그럼에도 불구하고 컨설턴트를 자주 고용하는 회사(짧은 시간에 많은 소스 코드를 이해해야 하는 회사), 개발자가 자주 로그인하고 그만두는 회사, 또는 핵심 개발자가 성공할 것이라고 장담하고 싶지 않은 회사의 경우 영원히 머물고 절대 직업을 바꾸지 마세요 -- Hibernate와 다른 표준 프레임워크는 제가 생각하기에 꽤 좋은 아이디어입니다.
/에이스
Spring과 Hibernate는 마스터하기 까다로운 프레임워크입니다.프레임워크를 파악하려고 노력하는 동안 마감 기한이 촉박한 프로젝트에서 이를 사용하는 것은 좋은 생각이 아닐 수도 있습니다.
프레임워크의 이점은 기본적으로 일관된 코드가 제품이 될 수 있는 플랫폼을 제공하려고 노력한다는 것입니다.경험을 통해 개발자가 프레임워크 설정 모범 사례를 경험하도록 하는 것이 좋습니다.
애플리케이션 및/또는 데이터베이스의 디자인에 따라 프레임워크가 성능을 방해하지 않도록 하기 위해 피해야 할 단점도 있습니다.
내 생각에 Spring의 가장 큰 장점은 특히 느슨한 결합, 테스트 및 더 많은 인터페이스와 같은 더 나은 개발 관행을 장려하고 가능하게 한다는 것입니다.Spring이 없는 Hibernate는 정말 고통스러울 수 있지만 둘을 함께 사용하면 매우 유용합니다.
기존 프로젝트를 어떤 프레임워크로든 개조하는 것은 고통스러울 수 있지만 리팩토링 프로세스는 종종 장기적인 유지 관리 측면에서 심각한 이점을 제공합니다.
나는 이것에 대한 많은 게시물에 동의해야합니다.나는 다양한 설정에서 두 가지를 광범위하게 사용했습니다.디자인 결정을 취소할 수 있다면 Hibernate를 사용했을 것입니다.우리는 실제로 세계 최고의 접근 방식을 위해 Hibernate를 iBatis로 바꾸고 Spring-JDBC를 교체하기 위해 우리 제품 중 하나의 릴리스에 예산을 책정했습니다.새로운 개발자가 Spring-JDBC, Spring-MVC, Spring-Ioc 및 iBatis를 사용하여 Hibernate로 작업을 수행하는 것보다 더 빠르게 작업할 수 있습니다.
이 KISS 개발자에게는 Hibernate가 너무 복잡합니다.그리고 DBA가 데이터베이스에서 생성된 SQL을 확인하고 최적화된 버전으로 다시 보내면 천국이 최대 절전 모드를 지원합니다.
가장 높은 답변은 Hibernate가 제대로 문서화되어 있지 않다고 언급합니다.나는 온라인 참조 매뉴얼이 더 완벽할 수 있다는 데 동의합니다.그러나 Hibernate의 저자들이 쓴 책 'Hibernate를 사용한 Java 지속성'는 모든 Hibernate 사용자가 꼭 읽어야 할 매우 완전한 책입니다.
@slim - 오늘도 아침에도 여러분과 함께합니다.
전형적인 사례같네요 여기서 발명되지 않은 증후군.Spring을 좋아하지 않는다면 자체 프레임워크를 롤링하는 것(인정 여부에 관계없이)보다는 다른 옵션을 고려해야 합니다. 기이스 가능성으로 떠오릅니다.또한 피코컨테이너.필요한 것에 따라 다른 것들도 있습니다.
Spring과 Hibernate는 확실히 삶을 더 쉽게 만들어줍니다.처음에는 이를 시작하는 데 약간의 시간이 걸릴 수 있지만 나중에 확실히 이점을 얻을 수 있습니다.이제 XML이 주석으로 대체되므로 수백 줄의 XML을 입력할 필요도 없습니다.
고려해 볼 수도 있습니다. 앱퓨즈 학습 곡선을 줄이려면:애플리케이션을 생성하고 연구하고 적용한 후 시작하세요.
프레임워크는 악하지 않습니다.Java SDK도 프레임워크입니다.
그들이 아마도 싸울 것은 프레임워크 확산.단지 시작하기 위해 프레임워크를 프로젝트에 가져와서는 안 되며, 합리적인 시간에 일관된 가치를 제공해야 합니다.모든 프레임워크에는 학습 곡선이 필요하지만 나중에는 향상된 생산성과 기능으로 보상을 받을 것입니다.
일관되지 않은 데이터베이스 사용, 복잡한 캐시 메커니즘 또는 기타 수많은 이유로 인해 디버깅하기 어려운 코드로 인해 어려움을 겪고 있는 경우.Hibernate는 큰 가치를 더해줄 것입니다.학습 곡선(저에게는 약 1개월의 실제 작업이 소요됨)을 제외하면 기본 사항을 설명해 줄 사람이 주변에 있다면 어떤 함정도 없었습니다.
