http://www.noorm.org/
Efficient persistence for Java applications
자바 어플리케이션을 위한 효율적인 퍼시스턴스(persistence)
NoORM 은 코드 생성기(code generator) 및 자바 오픈소스 프로젝트 (아파치 라이센스)
NoORM는 코드 생성기를 제공하며 손쉽게 오라클 데이터베이스의 관계형 데이터에 대한 액세스를 자동화하는 런타임 라이브러리를 제공하는 자바 오픈 소스 프로젝트 (아파치 라이센스, 소스 코드와 이슈는 Java.Net 에서 확인) 입니다. NoORM은 현재까지는 오라클에 제한되어 있지만, 버전 2.0에서는 MySQL에 대해서도 지원을 제공할 것입니다. 많은 다른 툴과 라이브러리가 유사한 기능을 제공하고 있지만, NoORM는 데이터베이스 중심의 접근 방식을 따른다. 적절한 관계형 데이터 모델을 기반으로 NoORM는 자바 애플리케이션을 위해 오라클의 강점을 이끌어내는 자바 빈즈, 자바 열거형 및 Java 서비스에 필요한 자바 코드를 생성 할 수 있습니다. 특히, NoORM를 사용하여 당신에게 다음과 같은 혜택을 가져올 수 있습니다 :
NoORM is a Java open source project (Apache Licensing, source code and issue tracking at Java.Net) providing code generators and a runtime library to simplify and automate access to relational data residing in an Oracle database. Even though NoORM is still presently limited to Oracle, version 2.0 will offer support also for MySQL. In distinction to many other tools and libraries providing functionality in this area, NoORM follows a consequent database-centric approach. Having a proper relational data model, NoORM can generate the required Java code for Java Beans, Java Enums and Java Services to exploit the power of Oracle for Java applications. In particular, using NoORM can bring you the following benefits:
가파른 학습 곡선 : 런타임 환경설정 없음, 복잡한 API 없음. (실질적으로 의존적인 API가 거의 없음!)
놀라운 성능 : 성능 벤치 마크 자체에 복잡한 문제이지만, 우리는 자신있게 NoORM이 경쟁자들 보다 거의 항상 빠를 것이라도 주장할 수 있습니다.
관심사의 완전히 분리 : SQL은 클라이언트의 문제가 아니다! 데이터베이스 개체는 클라이언트 응용 프로그램에서 직접 해결해야 할 문제가 아닙니다! NoORM 응용 프로그램을 개발하는 것은 개발자도 데이터베이스 개체를 직접 조작하거나 데이터베이스 외부에서 SQL을 사용하지 않는다는 의미입니다!
향상된 코드 품질 : 코드 생성은 두 가지 장점이 있습니다 : 이기종 시스템을 위한 소프트웨어를 개발한다는 것은 항상 플랫폼 간의 중복이 어느 정도 발생하게 되어 있습니다. NoORM 데이터베이스 오브젝트에 액세스하기 위해 자바 코드를 생성하는 코드 생성기를 활용하면, 시스템 접속에 대한 코드를 생성하는 단 하나의 시스템만을 분석 할 수 있게 됩다. 코드 생성기의 두 번째 장점은 빌드 프로세스에서 런타임 시스템의 복잡한 작업을 '미리보기(preview)' 할 수 있다는 점 입니다. NoORM의 가장 복잡한 중요한 파트는 코드 생성기에 의해 구현되며, 이를 활용해 런타임 시점에 발생할 수 있는 잠재적인 문제점들을 빌드 시점에 점검할 수 있게 됩니다.
Steep learning curve: No runtime configuration, no complex API (actually almost no proprietary API at all!)
Extraordinary performance: Though performance benchmarking is a complex issue on its own, we can confidently assert that NoORM is almost always significantly faster than its competitors.
Clean Separation of Concerns: SQL is not a matter of the client! Database objects are not to be addressed directly from a client application! Developing applications with NoORM means that the developer neither addresses database objects directly nor uses SQL outside of the database!
Improved Code Quality: Code generation has two benefits: developing software for heterogeneous systems always includes some degree of redundancy across the different systems and platforms in use. Code generators can analyze one system to generate code for a connecting system, like NoORM generates Java code to access database objects.
A second benefit of code generators evolves from the pre-drawing of complex operations from the runtime system already in the build process. A significant part of the complexity of NoORM is implemented with the code generators, which will cause potential problems to occur at build time rather than at runtime!
왜 새로운 ORM 도구 또는 프레임워크가 필요합니까?
이 글을 쓰는 시점에서 이미 다양한객체 관계형 매핑 (ORM) 라이브러리와 프레임워가 나와 있습니다. 그럼, 왜 우리에게 새로운 툴이 더 필요할까요?
오라클 데이터베이스의 기능 활용 범위(혹은 수준)는 오라클을 사용하는 다수의 기업 자바 프로젝트 사이에 크게 다릅니다. 대부분의 엔터프라이즈 자바 프로젝트는 주로 자바 세계의 근원적인 설계 사상에 의해 구축됩니다. 많은 (기업) 자바 아키텍트들은 자바로 생각(Thinking in Java) 합니다.
Do we need another ORM Tool or Framework for Java?
There are plenty of ORM-tools (ORM : Object-Relational-Mapping) , libraries and frameworks available for Java at the time of this writing. So, why do we need one more?
The utilization of the features of an Oracle database varies significantly between numerous enterprise Java projects using Oracle. Many enterprise Java projects are mainly driven by architectural guidelines having their origin in the Java world. Many (enterprise) Java architects perceive themselves as "thinking in Java" (this is not to be understood as a hidden cross reference to the great Java book "Thinking in Java" from Bruce Eckel).
그 자체가 나쁜 것은 아닙니다. 그러나, 복잡한 엔터프라이즈 자바 프로젝트를 고려하면, 거의 항상 관계형 데이터베이스 관리 시스템을 사용하여 데이터를 유지하게 마련인데, 앞서의 접근방안은 관계형 데이터베이스 시스템의 역할 및 성능을 제대로 이끌어내지 못할 수 있다.
데이터베이스의 성능을 제대로 활용하면 응용 프로그램의 아키텍처와 디자인을 주목할만큼 개선할 수 있습니다.
This is not a bad thing per se. However, considering complex enterprise Java projects, which almost always use a relational database management system to persist data, this approach could easily result in an underestimation of the role and power of the relational database system.
Leveraging the power of the database could significantly improve architecture and design of an application.
NoORM 은 오라클 데이터베이스 엑세스를 구성하는데 도움이 되는 또 다른 도구이지만, 소프트웨어 기능 요구사항을 기술하기 위한 새로운 스펙을 제시하지는 않습니다. NoORM 을 사용하기 위해 새로운 고유 API를 배울 필요가 없습니다. SQL 코드의 관리 및 유지는 생성기 설정의 간단한 쿼리 선언으로 이루어지며, 기존의 지식과 코드를 활용해 SQL을 구성할 수 있습니다.
Though NoORM is yet another tool to help you organize Oracle database access from a Java application, it does not introduce new specifications to specify your requirements. You do not even have to learn a new proprietary API to use NoORM. Managing and maintaining your SQL code is done through simple query declarations in the generator configuration or by using PL/SQL, so even for SQL you can build upon existing knowledge and/or code.
"NoORM"이름은 무엇을 의미 하는가?
NoORM이 실질적인 의미는 "no ORM"이나, 실제로 그런 것은 아닙니다. 자바와 같은 객체지향 프로그래밍 환경에서 관계형 데이터베이스를 사용하기 위해서는 언제나 "ORM(Object Relational Mapping)"이 필요합니다. 즉, 데이터베이스 데이터와 어플리케이션 데이터 간의 매핑(mapping) - 데이터베이스의 데이터가 어플리케이션에서 이용되는 방법 - 을 정의해야 하는 것입니다. NoORM 은 종종 '황금률'이라고 불리는 단순히 자바 클래스에 대에티베이스 테이블 또는 뷰를 매핑하는 아주 기본적인 ORM 패러다음을 사용합니다.
What does the name "NoORM" mean?
NoORM actually means "no ORM", which, of course, is not really true, since using a relational database system with an object-oriented programming environment like Java always requires some "ORM", i.e., you are required to define some mapping between database data and your application data, resp. the way the database data is utilized in your application. NoORM uses the very basic ORM paradigm often referred to as "golden rule", which simply maps a database table or view to a Java class (i.e., rows of a table or view are represented as object instances of the Java class representing the table or view).
사실상, 데이터를 매핑하는 것에 대해 더 할 말은 없습니다. NoORM은 최소한 매핑을 통해 중복을 최소화하는 기술을 제공하는 ORM 도구로 고려할 만 합니다. 좀 더 깊이 얘기하자면, NoORM 은 관계형 데이터 모델 (혹은 ER-모델)의 상세한 특성들을 다루지 않는데, 관계 조언, 제약 조건 등은 데이터베이스에 실행 책임을 맡기는 것이 최선입니다.
Effectively, there is not much more to say about mapping data, i.e., NoORM can be considered as an ORM-tool reducing the required redundancy implied by the mapping to the bare minimum. In particular, this means that NoORM does not care about the detailed characteristics of your relational data model or ER - model, but leaves this part to the database, which is effectively the best place to deal with relationships, joins, constraints, etc.
대상 그룹
NoORM 은 분명히 오라클을 사용하는 모든 엔터프라이즈 자바 프로젝트에 대해 관심을 두고 있습니다. 특히 PL / SQL을 사용할 수 있게 하는 것입니다. (그것뿐 아니라!).
Target Group
NoORM is obviously of interest for all enterprise Java projects using Oracle, in particular those which make use of PL/SQL (but not only!).
엔터프라이즈 자바 개발자들에게 있어 다른 ORM 도구들이 익숙하지만, PL/SQL 사용에 있어서는 의문이 있습니다. PL/SQL을 사용하지 않는 프로젝트 또한 그렇습니다. 하지만, NoORM 은 비즈니스 로직을 stored procedure에 저장된 PL/SQL로 이전할 것을 요구하지는 않습니다. PL/SQL 적용 범위는 매우 가변적이며 프로젝트의 요구사항에 따라 달랍니다. 기본적으로 PL / SQL의 사용에 관한 두 가지 시나리오를 고려할 수 있습니다. (물론, 상상할 수 있는 모든 시나리오 또한 가능합니다.)
It is quite natural that enterprise Java developers familiar with other ORM - tools question the usage of PL/SQL, in particular for projects which are not using PL/SQL yet. However, NoORM does not require moving your business logic into PL/SQL stored procedures. The degree of PL/SQL usage is quite variable and depends on your projects needs. Basically two scenarios concerning the usage of PL/SQL are possible (though any thinkable scenario in the range in between is possible, too):
PL/SQL 패키지로서의 SQL 컨테이너 : 어떤 ORM 도구를 사용하던 SQL을 사용할 수 밖에 없고, SQL을 어디에 저장할 지 고민해야 합니다. 엔터프라이즈 자바 어플리케이션 내부는 SQL을 관리하기 위한 적절한 저장소가 아닙니다. SQL을 XML 파일 같은 리소스 파일들에 저장하거나, 정적 클래스 변수 혹은 어노테이션에 저장하던 간에 둘 다 자바 어플리케이션 환경에서는 아무런 의미 없는 형식으로 저장됩니다. 데이터베이스로 SQL 명령이 전송될 때까지 SQL은 아무런 가치(의미)가 없습니다.그러므로, 궁극적으로 SQL 명령의 존재 의의가 있는 데이터베이스에 저장하는 것이 너무나 자연스러운 것입니다.
PL/SQL packages as SQL - container: Whatever ORM - tool you use, in any case you have to deal with SQL, in particular deciding where to store your SQL. We think that an enterprise Java application does not seem to be the appropriate place for maintaining SQL. Whether SQL is stored in (proprietary) resource files like XML - files, in static class variables or in (proprietary) annotations, in either case SQL is kept in a format which is actually meaningless to its environment (here: the Java application). The SQL does not become meaningful until it is submitted to the database. So it sounds quite natural to store SQL in a place which ultimately gives the SQL statements their meaning - in the database.
SQL 컨테이너로서의 PL / SQL 패키지는 SQL 코드의 검증 기능을 포함하는 선택 가능한 옵션입니다. 결국, PL/SQL을 sql 컨테이너로 사용하기 위한 방법을 학습하는 것은 엔터프라이즈 자바 어플리케이션에서 SQL을 관리하는 방법을 익히는 것보다 많은 것을 노력을 요구하지 않습니다.
SQL로 PL / SQL을 사용하는 방법을 학습 - (절대 PL / SQL 초보자 용) 용기 당신의 엔터프라이즈 자바 응용 프로그램과 함께 저장 SQL에 사용할 수있는 독점적 인 방법 중 하나를 배우는 것보다 더 요구하지 않습니다.
비즈니스 로직을 포함하는 PL / SQL : PL / SQL이 이미 프로젝트에 대한 비즈니스 로직의 중요한 부분을 포함하는 경우, 어쨌든 NoORM 을위해 잘 준비가 되어 있는 것입니다.
Using PL/SQL packages as SQL - container is a viable option here, including the validation of the SQL code. In the end, learning how to use PL/SQL as a SQL - container (for an absolute PL/SQL beginner) is not more demanding than learning one of the proprietary methods available to store SQL with your enterprise Java application.
PL/SQL to contain business logic: When PL/SQL is already used in your projects for significant parts of your business logic, you are well prepared for NoORM anyway.
그러나, SQL 문 대다수를 사용하는데 있어서 PL/SQL을 사용할 필요는 없다. SQL 문장의 대부분은 SELECT * <하나의 엔티티> WHERE A = X와 B = Y FROM ...' 와 같은 사소한 형식을 따른다. 이러한 단순한 형식의 쿼리들은 쿼리 생성을 위한 각종 설정과 쿼리(코드) 생성기에 손쉽게 통합될 수 있다. 데이터베이스 뷰를 이용해 복잡한 쿼리 조차 쿼리를 선언하는 출발점으로 활용할 수 있고, 거의 모든 쿼리 또한 간결한 형식으로 제공할 수 있다.
However, for the majority of SQL statements it is not even necessary to use PL/SQL. The vast majority of SQL statements follow a rather trivial format: SELECT * FROM <one single entity> WHERE A = x AND B = y ...
Queries with this trivial format can easily be integrated (and generated) using the code generator for an appropriate query declaration as part of the generator configuration. By using database views it is even possible to provide even complex SQL as starting point for the declared query, turning almost all queries into this trivial format.
"데이터베이스 중심"코드 생성의 기본 원리는 직접 데이터베이스 객체에 접근하지 않는다는 것이다. 테이블, 뷰 등의 데이터베이스 객체의 이름은 생성기 설정에서만 사용되면, 손으로 만든(hand-made) 자바 코드에서 사용되지 않는다.
The basic principle of "database-centric" code-generation is that the developer using NoORM will never address a database object directly (the names of database objects, i.e., tables, views, etc. are used in the generator configuration only, but never in the ("hand-made") Java code.
왕복 엔지니어링
엔터프라이즈 소프트웨어 환경의 시스템이나 구성 요소 간의 매핑 데이터는 항상 코드 및 사양에 약간의 고유 중복을 포함한다. NoORM로 구현된 최소한의 객체 관계형 매핑 접근 방식은 완전 자동화 된 왕복 엔지니어링 솔루션을 실현한다. 이것은 데이터베이스 데이터에 대한 표현과, 필요한 기능이 완전히 NoORM 코드 생성기에 의해 생성된다는 것을 의미한다.
Roundtrip Engineering
Mapping data between systems or components of enterprise software environments always includes some intrinsic redundancy in code and specifications. The minimal object-relational-mapping approach implemented with NoORM is realized as fully automated roundtrip engineering solution. This means that the code required to represent database data and functionality is completely generated by the NoORM code generator.
