Flex Java BlazeDS 대시 보드 - Spring/JDBC 또는 Hibernate를 사용 하시겠습니까?

Question

저는 근무하는 회사의 IT 모니터링 대시 보드를 개발 중입니다. 시스템은 주로 파일, 데이터베이스 및 서버 모니터링을 수행합니다. 사용자가 시스템에 대한 정적 데이터 (예 : 파일 위치, 서버 이름 등)를 구성 할 수있는 시스템의 작은 부분이 있습니다 ...

그래서 앱으로. 대시 보드가 될 것입니다. 많은 응용 프로그램은 모든 모니터링보기를 업데이트하기 위해 플렉스 클라이언트에 데이터를 게시하는 것으로 구성됩니다. 따라서 제한된 데이터베이스 활동, 즉 삽입/갱신/삭제가있을 것입니다.

저는 현재 백엔드 Java 코드에서 Spring/JDBC 조합을 사용하고 있습니다. 나는 최근에 (Spring/JDBC에 비해) CRUD 연산 측면에서 사용하기 쉽도록 Hibernate로 이동하는 것에 대해 생각했다.

누구에게이 아이디어가 있습니까? 내가하고있는 일은 Spring/JDBC만큼 충분하다. Spring/JDBC는 확장 가능합니까? 대시 보드가 사용자 (확장 성) 및 기능면에서 (데이터베이스 운영이 늘어남에 따라) 커지면 앞으로 더 많은 것을 찾고 있습니다.

추신 : 이전에 최대 절전 모드를 사용하지 않았지만 JDO/Kodo와 Toplink를 사용하여 최대 절전 모드와 동일한 방식으로 작동합니다.

감사 마이크 내가 당신을 추측하고

Answer 1

Hibernate (및 대부분의 다른 ORM)과 Spring/JDBC의 주요 차이점은 대부분의 ORM은 원격 응용 프로그램에서 실제로 매우 문제가 될 수있는 "지연로드"를 지원한다는 것입니다. 당신이 Hibernate를 사용하고 있고 Address 객체들의 콜렉션을 가진 Person 클래스를 가지고 있다고 가정하자. Hibernate에게 Person 인스턴스를 요청하면 기본적으로 Person의 단순한 프로퍼티 만로드되고 "addresses"컬렉션은 빈 프록시가 될 것이다.당신이 처음으로 "주소들"에 접근 할 때, Hibernate는 데이터를 당신을 위해 주소 컬렉션에 마술처럼 "게으른로드"하기 위해 SQL을 실행할 것이다. lazy 주소를 가진 Person을 사용중인 serializer에 전달하면 전체 객체 그래프를 탐색하고 도달 할 수있는 모든 지연 프록시의 지연로드를 트리거합니다. 복잡한 객체 모델에서는 문자 그대로 수천 개의 SQL 쿼리가 서버로 전송되기 전에 객체 그래프를 완전히로드 할 수 있습니다. 즉, 전송되는 여러 메가 바이트의 데이터는 말할 필요가 없습니다.

DTO와 Hibernate를 사용하여 언급 된 다른 포스터 중 하나이며,이 게으른 로딩 문제를 해결하는 데 도움이되므로 바람직하지 않습니다. 기본적으로 모든 엔티티를 DTO로 랩 한 다음 DTO 만 리턴합니다. 앞의 예제를 확장하여 Person에 단일 Department 객체가 연결되어 있다고 가정합니다. PersonDto는 대신 "departmentId"속성을 가질 수 있습니다.이 속성은 액세스 할 때 기본 Department 객체의 "id"속성 만 가져옵니다. Hibernate 지연 엔티티 프록시는 항상 자신의 식별자로 채워지기 때문에 객체를 게으르지 않고이 데이터에 접근 할 수있다. PersonDto는 실제로 Department 객체를 시리얼 라이저에 노출시키지 않으므로,이를 걷고 모든 데이터를로드하려고 시도 할 수 없습니다.

Hibernate에서 DTO를 사용하는 대신에 Hibernate 게으른 프록시에 매우 멋진 일을하기 위해 하나의 대안이 있습니다. 그래서 그들은 시리얼 라이저와 잘 동작합니다. 더 자세히 알고 싶다면 Gilead 프로젝트를보십시오.

또한 확장성에 대해서도 언급했지만 물론 대답은 "다릅니다."입니다. :) 더 많은 사용자를 다루는 관점에서 Spring/JDBC를 사용하여 SQL을 튜닝하는 것이 더 쉬울 것이다. 이는 성능을 향상시키고 데이터베이스의 부하를 줄여줌으로써 더 많은 사용자를 지원할 수있게한다. 하지만 Hibernate는 코드 유지 보수성과 할 일의 엄청난 양의 측면에서 지루한 crud 기능을 자동화하기 때문에 더 나은 옵션을 제공 할 수 있습니다.

Answer 2

는 술집/하위 기능과 함께 불꽃 DS의 원격 클래스 기능을 살펴 보았다. 이렇게하면 효과적으로 Java 클래스를 액션 스크립트 클래스에 매핑 할 수 있으며,이 클래스를 와이어를 통해 보낼 수 있습니다.

이미 사용할 수있는 서버에 정의 된 엔티티 모델이있는 경우 엔티티/도메인 수준에서 작동하는 것처럼 최대 절전 모드 또는 유사한 기술을 쉽게 통합 할 수 있습니다.

주석 처리 된 엔티티 모델에서 스키마를 생성하기 위해 하향식 접근 방식을 사용하고 최대 절전 모드를 사용할 수 있습니다. 나는 spring/jdbc에 익숙하지 않지만, 최대 절전 모드는 단순한 애플리케이션이라도 크게 단순화 할 수있다.

확장 성의 측면에서 보면 hibernate는 2 차 수준/분산 캐싱과 같은 많은 고급 기능을 가지고 있으므로 문제가되지 않아야합니다.

클래스에서 JPA/최대 절전 모드 매핑을 생성하는 방법을 배우려면 netbeans 자습서를 살펴보십시오.

Answer 3

Kodo/JDO를 사용했다면 DataNucleus는 단순해야합니다. 객체 그래프의 복잡성에 따라 JDBC와 같은 해결책을 찾아야 할 필요가 있는지 여부에 달려 있습니다. 당신은 데이터의 관계 복잡성에 대한 아이디어를주지 않습니다. DataNucleus를 사용하면 Kodo와 마찬가지로 L2 캐시를 사용할 수 있으므로 확장성에 많은 도움을줍니다.

--Andy (DataNucleus)

Answer 4

내가 언급 한 모든 이유에 대해 최대 절전 모드로 이동하고 자바와 플렉스 사이의 통신을 위해 DTO 패턴을 사용합니다. 아마 당신은 Hibernate 도메인 객체를 직접 전선으로 전송하고 싶지 않을 것이다.