一生牛步行

NoORM의 디자인과 컨셉은 오라클의 의존하지 않지만, 스토어드 프로시져(stored procedue)  사용하는데 있어서는 데이터베이스 세계의 공통 표준이 부족하기 때문에 오라클에 종속될 수 밖에 없습니다. NoORM 은 오라클 데이터베이스 10gR2 혹은 상위 비전을 지원하며, 오라클 익스프레스 에디션을 포함한 모든 에디션을 지원합니다.

Though design and concept of NoORM do not depend on Oracle, the usage of stored procedures, which still lack a common standard in the database world, currently requires the usage of Oracle. NoORM supports Oracle database 10gR2 or higher. All editions are supported, including Oracle Express Edition.

NoORM은 Java 6 혹은 상위 버전을 필요로 합니다.

NoORM requires Java 6 or higher.

NoORM은 두개의 파트로 구성되어 있습니다. 코드 생성기(code generator)와 런타임 라이브러리(runtime library)입니다.  코드 생성기는 어플리케이션 개발 단계에서 필요하며, 런타임 라이브러리는 개발 및 어플리케이션 실행 과정에서 모두 필요합니다. NoORM 코드 생성기 없이 어플리케이션을 개발할 수 있지만 권장하지는 않습니다. 개발 생산성 향상은 코드 생성기 활용으로 인해 야기됩니다.

NoORM comes with two parts: the code generators and the runtime library. The code generators are required for application development, the runtime library is required for both, development and your applications runtime. Though you can develop applications without the NoORM code generators, this approach is not recommended. The improvement of development productivity is primarily caused by the usage of the code generators.

코드 생성기는 아파치 벨로시티(Apache Velocity)를 사용합니다. 코드 생성기는 다양한 옵션을 제공합니다. 고유한 환경 설정 메커니즘으로 인해 코드 생성기의 강점을 가려지지 않게끔, 코드 생성기는 환경설정을 위한 커스텀 XML 스키마를 포함한 메이븐(Maven) 플러그인 형태로 만들어져 있습니다. Maven 3 사용을 권장하지만, Maven 2 역시 지원합니다.

The code generators use Apache Velocity. Various configuration options are available for the code generators. To exploit the power of the code generators without the need for a new proprietary configuration mechanism, the code generators are wrapped into a Maven plugin using a custom XML schema for the configuration. We recommend the usage of Maven 3, though Maven 2 is also supported.

NoORM을 사용하기 위해서는 이어지는 자바 라이브러리들이 필요합니다. (코드 생성기 포함) Oracle JDBC 는 법적인 이유로 공개 메이븐 저장소에서 제공하지 않기 때문에 제공되지 않지만 나머지 의존성은 메이븐에 의해 자동으로 검색(resolve)됩니다.

The following Java libraries are required to use NoORM (including the code generators). Except for the Oracle JDBC driver, which is not provided by a public Maven repository for legal reasons, all other dependencies can be resolved automatically using Maven:

Oracle JDBC Driver (NoORM has been tested with all available Versions of the Oracle 10.2g, 11g and 12c series, note that for Oracle 12c you may have to add Oracle XML libraries to your classpath)

Velocity 1.7

SLF4J API 1.7.5

Logback Classic 1.0.13 (or any other logging library with support for SLF4J like log4j)

NoORM은 두개의 내장 PL/SQL 패키지를 포함합니다. NOORM_METADATA 패키지는 자바 코드 생성기를 위해 필요하며, 자동 클래스 검증(Automatic Class Validation) 기능을 런타임 시에 사용하고자 한다면 런타임 환경에서도 필요합니다. DYNAMIC_SQL 패키지는 런타임 시에 동적인 SQL 생성을 지원하기 위해 제공됩니다. 패키지들과 패키지에 필요한 부가적인 데이터베이스 요소들이 운영 중인 오라클 데이터베이스 스키마에 설치되어야 합니다. Maven SQL 플러그인을 사용하면 NoORM 데이터베이스 요소들과 어플리케이션 고유의 데이터베이스 객체에 대한 생성과 운영을 메이븐 빌드에 통합할 수 있기에 추천합니다. SQL 빌드 통합 섹션을 참조하면 좀 더 자세한 정보를 얻을 수 있습니다.

NoORM comes with two internal PL/SQL packages: package NOORM_METADATA is required by the Java code generator and, if you make use of the Automatic Class Validation feature, it is required at runtime, too. Package DYNAMIC_SQL provides support for Dynamic SQL generation at runtime. The packages and additional database objects required by these packages must be installed into your working Oracle database schema. It is recommended to use the Maven SQL Plugin to integrate the creation and maintenance of NoORM database objects and your own database objects with your Maven build. Refer to section SQL Build Integration for more information.

NoORM PL/SQL 패키지와 관련된 데이터베이스 요소들을 생성하는 필요한 SQL 스크립트들은 NoORM 런타임 라이브러리에 포함되어 있습니다. (JAR 파일 내의 /plsql 폴더)

The SQL scripts required to install the NoORM PL/SQL packages and associated database objects are bundled with the NoORM runtime library (under /plsql in the JAR-file)

샘플 스키마 

Sample Schema

이어지는 퀵스타트(quick start) 튜터리얼은 잘 알려진 오라클 샘플 스키마인 HR (인사 정보 : Human Resources)에 기초한 것입니다. 일부 오라클 에디션들은 사전 설치된 데이터베이스에 이 스키마를 포함하고 있습니다. (예를 들면, 오라클 익스프레스 에디션)  만일, 데이터베이스 설치에 HR 스키마가 포함되어 있지 않다면, 오라클 샘플 스키마 온라인 문서를 참조하기 바랍니다. 해당 도큐먼트에는 스키마 다이어그램과 샘플 스키마들에 대한 설명이 포함되어 있습니다.

The following quick-start tutorial is based on the well-known Oracle sample schema HR ("human resources"). Some Oracle editions contain this schema in the pre-installed database (e.g. Oracle Express Edition). If schema HR is not available with your database installation, refer to the Oracle Sample Schemas Online Documentation for more information about the sample schemas. The referred document also contains schema diagrams and explanations about the meaning of the sample schemas (Note that you may have to unlock the account prior to accessing it).

설정되어 있는 코드 생성기

Configuring the Code Generator

제대로 설정된 코드 생성기가 준비되어 있다면, 작업할 준비가 거의 된 것입니다. 그러나, 코드 생성기 설정을 시작하기에 앞서, 데이터베이스 객체들과 그에 상응하는 코드 생성에 관련된 자바 클래스들에 대해 빠르게 살펴 볼 필요가 있습니다.

With properly configured code generators, you are already close to code ready for operation. But before we start with the configuration of the code generators, we should have a quick look at the database objects and their corresponding Java class types, which are subject to code generation:

자바 빈(java bean)은 데이터베이스 테이블 혹은 뷰(view)를 표현합니다 : 데이터베이스 데이터를 자바 어플리케이션에서 사용하기 위해서는 데이터베이스 테이블 및 뷰에 포함된 데이터를 표현하는 클래스 명세가 필요합니다. NoORM은 테이블이나 뷰를 표현하는 자바 빈들을 생성합니다.

Java Beans representing database tables or views: To utilize database data in your Java application, we need a class specification to represent the data contained in database tables or views. NoORM generates Java Beans for tables or views of your choice for this purpose.

자바 열거형(Enums) 은 컨텐츠를 포함하는 데이터베이스 테이블들을 표현합니다 : 일부 테이블들은 어플리케이션 라이플 사이클의 단일 사이클에서 변하지 않는 데이터를 가지고 있습니다. 예를 들자면, 사전 부류의 컨텐츠(성별, 주문 유형, 상품 유형 등)를 포함한 테이블을 가지고 제3의 양식을 채우는 업무를 구현하는 것일 수도 있습니다.  이런 데이터 유형은 일반적으로 어플리케이션의 기능에 가깝고, 어플리케이션 기능이 수정될 때 값이 변경됩니다. 따라서, 테이블 컨텐츠를 자바 Enum 타입을 이용해 자바 어플리케이션 코드에 고정(hard-wiring)하는 것이 가능합니다. 보다 자세한 정보는 자바 Enums 생성 섹션을 참고하기 바랍니다.

Java Enums representing database tables including content: Some tables may contain data which does not change within one cycle of your application life-cycle (e.g. release). For instance, you may have a table with some dictionary-like content to fulfil requirements to the third normal form in your database model like gender, order types, product types, etc. Data of this kind is typically closely tied to the functionality of your application and does only change when your application is modified. Thus it is possible to hard-wire the tables content into your application using a Java Enum. Refer to section Generating Java Enums for more information.

PL/SQL 코드를 감싼 자바 서비스 혹은 DAO(Data Access Object) : NoORM는 PL/SQL 프로시져에 내장된 SQL 쿼리들을 지원합니다. 오라클 REF CURSOR 타입을 이용해 저장 프로시져에서 JDBC ResultSet을 반환하는 것도 가능합니다. 자바 코드 생성기는 PL/SQL 패키지들을 분석하고 상응하는 API 자바 클래스를 생성합니다. 또한 SQL 쿼리에서 참조하는 테이블들에 상응하는 자바 빈들도 생성합니다.

Java Services or Data Access Objects wrapping PL/SQL code: NoORM supports SQL queries embedded into a PL/SQL procedure, resp. PL/SQL package. By utilizing the Oracle type REF CURSOR it is possible to return a JDBC ResultSet from a stored procedure. The Java code generator analyzes your PL/SQL packages and creates a corresponding Java class providing the API of the package under consideration of the Java Beans generated for the entities addressed in the SQL queries. Whether you denote the generated Java classes as service or as DAO (Data Access Object) depends on the semantically richness of the PL/SQL and is up to your development team. Refer to section PL/SQL is easy for more information.

단순하고 전형적인 쿼리 : 대다수의 SQL 문들은 단순한 형태를 띄게 마련입니다. FROM 절에 하나의 테이블을 사용하고, WHERE 조건에 AND로 연결된 조건들을 선언하는 것입니다. 이러한 SQL 문을 위해 PL/SQL 패키지를 선언하는 것은 부담이 될 수 있습니다. NoORM 은 단순한 쿼리를 설정할 수 있는 옵션을 제공함으로써 간편한 개발 절차를 제공합니다.

Declared Queries for canonical trivial SQL statements: Most SQL statements are rather trivial, using a single entity in the FROM-clause and using WHERE-conditions combined by an AND. For these statements even the implementation of PL/SQL packages can be a burden. NoORM provides configuration options to declare simple queries, which simplifies the development process significantly.

The very first step for the Maven configuration is the plugin configuration. The NoORM generator plugin requires the database connection parameters as mandatory parameters. All application specific parameters are specified in a separate XML file (One can specify a location for the NoORM configuration file, the default location is src/noorm/configuration.xml).

We start with a code generator configuration for Java Beans only in the first step. Only a few configuration parameters are mandatory, so the NoORM Maven plugin configuration is pretty straight-forward:

Minimal but complete Maven pom.xml with a NoORM code generator configuration:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"

         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>noorm-tutorial</groupId>

    <artifactId>noorm-tutorial</artifactId>

    <version>1.0</version>

    <properties>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    </properties>

    <build>

        <plugins>

            <plugin>

                <groupId>org.noorm</groupId>

                <artifactId>noorm-generator</artifactId>

                <version>1.0.0</version>

                <dependencies>

                    <dependency>

                        <groupId>com.oracle</groupId>

                        <artifactId>ojdbc6</artifactId>

                        <version>11.2.0.4.0</version>

                    </dependency>

                    <dependency>

                        <groupId>ch.qos.logback</groupId>

                        <artifactId>logback-classic</artifactId>

                        <version>1.0.13</version>

                    </dependency>

                </dependencies>

                <executions>

                    <execution>

                        <goals>

                            <goal>generate-noorm</goal>

                        </goals>

                    </execution>

                </executions>

                <configuration>

                    <url>jdbc:oracle:thin:@localhost:1521:XE</url>

                    <username>hr</username>

                    <password>hr</password>

                </configuration>

            </plugin>

        </plugins>

    </build>

    <dependencies>

        <dependency>

            <groupId>ch.qos.logback</groupId>

            <artifactId>logback-classic</artifactId>

            <version>1.0.13</version>

        </dependency>

        <dependency>

            <groupId>org.noorm</groupId>

            <artifactId>noorm-runtime</artifactId>

            <version>1.0.0</version>

        </dependency>

    </dependencies>

</project>

Let's go step by step through this configuration.

The first part of a Maven plugin configuration is always about the plugin itself. The groupId and the artifactId specify the NoORM Java code generator. The dependency for the Oracle JDBC driver requires that the drivers library is available for your local Maven installation (for more information see section Local Maven Repository).

The NoORM Java code generator has only the execution goal generate-noorm, so this part will stay the same for any configuration.

The values for url, username and password in the configuration section are self-explanatory and already provide a working setting, when you have installed Oracle Express Edition.

We will start with a minimal generator configuration containing not more than the package names for the generated beans and services:

Minimal NoORM code generator configuration file (configuration.xml)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<generatorConfiguration xmlns="http://www.noorm.org/generator-configuration/1.0.0"

                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                        xsi:schemaLocation="http://www.noorm.org/generator-configuration/1.0.0

                                            http://www.noorm.org/xsd/generator-configuration-1.0.0.xsd">

    <beanJavaPackage name="org.noorm.tutorial.hr.beans"/>

    <serviceJavaPackage name="org.noorm.tutorial.hr.services"/>

</generatorConfiguration>

For a first minimal project this is indeed enough! You may use your favourite IDE or you may setup a Maven project manually to build this project. The NoORM code generator creates a Java Bean for each table or view in the addressed database schema. For the Oracle sample schema HR, this results in the following classes (assuming you have used the package names as described in the listed configuration.xml):

Java Bean Class generated by the NoORM Java code generator

org.noorm.tutorial.hr.beans.Countries

org.noorm.tutorial.hr.beans.Departments

org.noorm.tutorial.hr.beans.EmpDetailsView

org.noorm.tutorial.hr.beans.Employees

org.noorm.tutorial.hr.beans.GenericBeanValidator

org.noorm.tutorial.hr.beans.JobHistory

org.noorm.tutorial.hr.beans.Jobs

org.noorm.tutorial.hr.beans.Locations

org.noorm.tutorial.hr.beans.Regions

You will find the generated classes in your Maven project in target/classes/org/noorm/tutorial/hr/beans.

The directory for the generated services in target/classes/org/noorm/tutorial/hr/services contains a single class file called BeanDML. This class contains a complete API for all DML operations applicable for the generated beans (insert, update and delete for single objects and lists of objects).

Naming Conventions and Custom Name Mappings

Java developers and database engineers typically use different naming conventions. For the generated Java code, NoORM follows best practices used by the Majority of Java developers (Code Conventions for the Java Programming Language).

Usually, this results in class, method and attribute names, which slightly differ from database object names. Database names are typically in upper-case with underscores to separate different parts of a single name. NoORM removes underscores and changes names according to the Camel-Case mechanism, i.e., a Java Bean generated for table JOB_HISTORY gets the name JobHistory.

However, you may have special requirements concerning the names of you Java classes, methods and attributes. In this case, the generator configuration parameters tableNameMappings and columnNameMappings provide the required functionality to adjust the generated names (see Code Generator Reference).

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.