ORM 사용의 장점은 무엇입니까?

ORM 사용의 장점은 무엇입니까?

---

수작업으로 코딩 된 PHP 사이트에서 프레임 워크 기반 사이트로 이동하려는 웹 개발자로서 저는 한 ORM의 장점에 대해 많은 논의를 보았습니다. 특정 (?) 크기의 프로젝트에 유용 하고 엔터프라이즈 수준의 응용 프로그램에 더 중요합니다.

개발자로서 나에게 무엇을 제공합니까? 내 코드는 지금 사용하는 개별 SELECT 문과 어떻게 다릅니 까? DB 접근 및 보안에 어떤 도움이됩니까? DB 스키마와 사용자 자격 증명에 대해 어떻게 알 수 있습니까?

편집 : @duffymo는 나에게 분명 했어야하는 것을 지적했습니다. ORM은 OOP 코드에만 유용합니다. 내 코드는 OO가 아니므로 ORM이 해결하는 문제에 부딪히지 않았습니다.

---

나는 당신이 객체를 다루지 않는다면 ORM을 사용하는 데 별 의미가 없다고 말하고 싶습니다.

관계형 테이블 / 열이 개체 / 속성과 1 : 1로 매핑되는 경우 ORM을 사용하는 데 별 의미가 없습니다.

개체가 다른 개체와 1 : 1, 1 : m 또는 m : n 관계가없는 경우 ORM을 사용하는 데 별 의미가 없습니다.

복잡하고 수작업으로 조정 된 SQL이 있다면 ORM을 사용하는 데 별 의미가 없습니다.

데이터베이스에 저장 프로 시저를 인터페이스로 사용하기로 결정했다면 ORM을 사용하는 데 별 의미가 없습니다.

리팩토링 할 수없는 복잡한 레거시 스키마가있는 경우 ORM을 사용하는 데 별 의미가 없습니다.

그래서 여기에 그 반대가 있습니다.

1 : 1, 1 : m 및 m : n 개체 간의 관계가있는 견고한 개체 모델이있는 경우에는 저장 프로 시저가없고 ORM 솔루션이 제공하는 동적 SQL과 마찬가지로 반드시 ORM을 사용하십시오.

이와 같은 결정은 항상 선택입니다. 선택, 구현, 측정, 평가.

---

ORM은 데이터 액세스 문제에 대한 해결책으로 과장되고 있습니다. 개인적으로 엔터프라이즈 프로젝트에서 사용한 후에는 엔터프라이즈 애플리케이션 개발을위한 솔루션이 아닙니다. 어쩌면 그들은 작은 프로젝트에서 일할 수도 있습니다. 우리가 특히 nHibernate에서 경험 한 문제는 다음과 같습니다.

1. 구성 : ORM 기술에는 테이블 스키마를 개체 구조로 매핑하기위한 구성 파일이 필요합니다. 대기업 시스템에서는 구성이 매우 빠르게 증가하고 생성 및 관리가 매우 어려워집니다. 또한 비즈니스 요구 사항과 모델이 민첩한 환경에서 지속적으로 변화하고 진화함에 따라 구성 유지 관리가 지루하고 유지 관리가 어려워집니다.

2. 사용자 지정 쿼리 : 정의 된 개체에 맞지 않는 사용자 지정 쿼리를 매핑하는 기능은 프레임 워크 공급자가 지원하지 않거나 권장하지 않습니다. 개발자는 임시 개체 및 쿼리를 작성하거나 필요한 데이터를 얻기 위해 사용자 지정 코드를 작성하여 해결 방법을 찾아야합니다. 단순한 선택보다 복잡한 경우에는 정기적으로 저장 프로 시저를 사용해야 할 수 있습니다.

3. 소유권 바인딩 : 이러한 프레임 워크는 컴퓨터 과학 산업에서 표준화되지 않은 독점 라이브러리 및 독점 개체 쿼리 언어를 사용해야합니다. 이러한 독점 라이브러리 및 쿼리 언어는 필요한 경우 변경에 대한 유연성이 거의 또는 전혀없이 서로 협력 할 수있는 상호 운용성없이 애플리케이션을 공급자의 특정 구현에 바인딩합니다.

4. 개체 쿼리 언어 : 개체 모델에 대한 쿼리를 수행하기 위해 개체 쿼리 언어라는 새로운 쿼리 언어가 제공됩니다. 데이터베이스에 대한 SQL 쿼리를 자동으로 생성하고 사용자는 프로세스에서 추상화됩니다. 객체 지향 개발자에게 이것은 SQL 작성 문제가 해결되었다고 느끼기 때문에 이점으로 보일 수 있습니다. 실용성의 문제는 이러한 쿼리 언어가 대부분의 실제 응용 프로그램에 필요한 중급 SQL 구문 중 일부를 지원할 수 없다는 것입니다. 또한 개발자가 필요한 경우 SQL 쿼리를 조정하는 것을 방지합니다.

5. 성능 : ORM 계층은 리플렉션 및 인트로 스펙 션을 사용하여 개체를 인스턴스화하고 데이터베이스의 데이터로 채 웁니다. 이는 처리 측면에서 비용이 많이 드는 작업이며 매핑 작업의 성능 저하를 추가합니다. 튜닝 옵션없이 최적화되지 않은 쿼리를 생성하도록 변환 된 개체 쿼리는 데이터베이스 관리 시스템의 성능 저하와 과부하를 유발합니다. SQL 성능 튜닝은 프레임 워크가 자동 생성되는 SQL 제어에 대한 유연성을 거의 제공하지 않기 때문에 거의 불가능합니다.

6. 긴밀한 결합 :이 접근 방식은 모델 개체와 데이터베이스 스키마간에 긴밀한 종속성을 만듭니다. 개발자는 데이터베이스 필드와 클래스 필드 간의 일대일 상관 관계를 원하지 않습니다. 데이터베이스 스키마를 변경하면 개체 모델 및 매핑 구성에 파급 효과가 있으며 그 반대의 경우도 마찬가지입니다.

7. 캐시 :이 접근 방식은 또한 개체의 상태를 유지 관리 및 추적하고 캐시 된 데이터에 대한 데이터베이스 왕복을 줄이는 데 필요한 개체 캐시 및 컨텍스트를 사용해야합니다. 이러한 캐시는 다중 계층 구현에서 유지 관리 및 동기화되지 않으면 데이터 정확성 및 동시성 측면에서 상당한 영향을 미칠 수 있습니다. 종종이 문제를 해결하기 위해 타사 캐시 또는 외부 캐시를 연결해야하므로 데이터 액세스 계층에 큰 부담이 추가됩니다.

분석에 대한 자세한 내용은 http://www.orasissoftware.com/driver.aspx?topic=whitepaper를 참조하십시오.

---

매우 높은 수준에서 : ORM은 객체 관계형 임피던스 불일치를 줄이는 데 도움이됩니다. 이를 통해 많은 구문 분석 / 직렬화를 직접 수행하지 않고도 관계형 데이터베이스에서 전체 라이브 개체를 저장하고 검색 할 수 있습니다.

개발자로서 나에게 무엇을 제공합니까?

우선 건조 상태를 유지하는 데 도움이됩니다. 스키마 또는 모델 클래스는 권한이 있으며 다른 클래스는 자동으로 생성되어 버그 수와 보일러 플레이트 코드 양을 줄입니다.

마샬링에 도움이됩니다. ORM은 일반적으로 개별 열의 값을 적절한 유형으로 마샬링하므로 직접 구문 분석 / 직렬화 할 필요가 없습니다. 또한 자신을 감싸 야하는 단순히 행 개체가 아닌 DB에서 완전히 형성된 개체를 검색 할 수 있습니다.

내 코드는 지금 사용하는 개별 SELECT 문과 어떻게 다릅니 까?

쿼리는 행이 아닌 개체를 반환하므로 새 쿼리를 만드는 대신 속성 액세스를 사용하여 관련 개체에 액세스 할 수 있습니다. 일반적으로 필요할 때 SQL을 직접 작성할 수 있지만 대부분의 작업 (CRUD)에서 ORM은 영구 개체와 상호 작용하는 코드를 더 간단하게 만듭니다.

DB 접근 및 보안에 어떤 도움이됩니까?

일반적으로 ORM에는 쿼리 작성 (예 : 속성 액세스)을위한 자체 API가 있으므로 SQL 주입 공격에 덜 취약합니다. 그러나 필요한 경우 이상한 작업을 수행 할 수 있도록 생성 된 쿼리에 자신의 SQL을 삽입 할 수있는 경우가 많습니다. 이러한 삽입 된 SQL은 사용자 자신을 삭제해야하지만 이러한 기능을 사용하지 않는 경우 ORM은 사용자 데이터를 자동으로 삭제해야합니다.

DB 스키마와 사용자 자격 증명에 대해 어떻게 알 수 있습니까?

많은 ORM은 스키마를 검사하고 데이터베이스의 개체와 상호 작용할 수있는 모델 클래스 집합을 구축하는 도구와 함께 제공됩니다. [데이터베이스] 사용자 자격 증명은 일반적으로 설정 파일에 저장됩니다.

---

데이터 액세스 계층을 직접 작성하는 경우 본질적으로 고유 한 기능이 부족한 ORM을 작성하는 것입니다.

Oren Eini에는 DAL / ORM에 필요한 필수 기능이 무엇인지, 그리고 시간이 지나면 직접 작성하는 것이 나쁜 생각이되는 이유를 요약 한 멋진 블로그가 있습니다. http://ayende.com/Blog/archive/2006/05/12 /25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

편집 : OP는 다른 답변에서 그의 코드베이스가 객체 지향적이지 않다고 언급했습니다. 개체 매핑을 다루는 것은 ORM의 한 측면 일뿐입니다. 액티브 레코드 테이블 1 : 패턴으로 ORMs 객체가 1지도 시나리오에서 여전히 유용한 방법의 좋은 예입니다.

---

다른 ORM에 대해서는 말할 수 없습니다. Hibernate (Java의 경우)뿐입니다.

Hibernate는 다음을 제공합니다.

• 런타임에 프로덕션 시스템의 테이블에 대한 스키마를 자동으로 업데이트합니다. 때로는 수동으로 일부 항목을 업데이트해야하는 경우도 있습니다.
• 고아 데이터를 생성하는 잘못된 코드를 작성하지 못하도록하는 외래 키를 자동으로 생성합니다.
• 연결 풀링을 구현합니다. 여러 연결 풀링 공급자를 사용할 수 있습니다.
• 더 빠른 액세스를 위해 데이터를 캐시합니다. 여러 캐싱 공급자를 사용할 수 있습니다. 또한 여러 서버를 함께 클러스터링하여 확장 할 수 있습니다.
• 응용 프로그램을 다른 데이터베이스로 쉽게 이식 할 수 있도록 데이터베이스 액세스를보다 투명하게 만듭니다.
• 쿼리를 더 쉽게 작성할 수 있습니다. 일반적으로 'join'을 세 번 작성해야하는 다음 쿼리는 다음과 같이 작성할 수 있습니다.
  • "i.customer.address.city =?" 특정 도시의 모든 송장을 검색합니다.
  • 송장 개체 목록이 반환됩니다. 그런 다음 invoice.getCustomer (). getCompanyName ();을 호출 할 수 있습니다. 데이터가 아직 캐시에없는 경우 데이터베이스는 백그라운드에서 자동으로 쿼리됩니다.

하이버 네이트 스키마를 생성하기 위해 데이터베이스를 리버스 엔지니어링하거나 (직접 시도하지 않았 음) 스키마를 처음부터 생성 할 수 있습니다.

물론 새로운 기술과 마찬가지로 학습 곡선이 있지만 그만한 가치가 있다고 생각합니다.

필요한 경우 더 낮은 SQL 수준으로 내려가 최적화 된 쿼리를 작성할 수 있습니다.

---

주요 이점 :

1. 데이터베이스 추상화
2. API 중심 설계 정신
3. 높은 수준 == 근본적인 수준에서 걱정할 필요가 적습니다 (당신을 위해 생각했습니다)

I have to say, working with an ORM is really the evolution of database-driven applications. You worry less about the boilerplate SQL you always write, and more on how the interfaces can work together to make a very straightforward system.

I love not having to worry about INNER JOIN and SELECT COUNT(*). I just work in my high level abstraction, and I've taken care of database abstraction at the same time.

Having said that, I never have really run into an issue where I needed to run the same code on more than one database system at a time realistically. However, that's not to say that case doesn't exist, its a very real problem for some developers.

---

Most databases used are relational databases which does not directly translate to objects. What an Object-Relational Mapper does is take the data, create a shell around it with utility functions for updating, removing, inserting, and other operations that can be performed. So instead of thinking of it as an array of rows, you now have a list of objets that you can manipulate as you would any other and simply call obj.Save() when you're done.

I suggest you take a look at some of the ORM's that are in use, a favourite of mine is the ORM used in the python framework, django. The idea is that you write a definition of how your data looks in the database and the ORM takes care of validation, checks and any mechanics that need to run before the data is inserted.

---

Personally I've not had a great experience with using ORM technology to date. I'm currently working for a company that uses nHibernate and I really can't get on with it. Give me a stored proc and DAL any day! More code sure ... but also more control and code that's easier to debug - from my experience using an early version of nHibernate it has to be added.

---

What does it give me as a developer?

Saves you time, since you don't have to code the db access portion.

How will my code differ from the individual SELECT statements that I use now?

You will use either attributes or xml files to define the class mapping to the database tables.

How will it help with DB access and security?

Most frameworks try to adhere to db best practices where applicable, such as parametrized SQL and such. Because the implementation detail is coded in the framework, you don't have to worry about it. For this reason, however, it's also important to understand the framework you're using, and be aware of any design flaws or bugs that may open unexpected holes.

How does it find out about the DB schema and user credentials?

You provide the connection string as always. The framework providers (e.g. SQL, Oracle, MySQL specific classes) provide the implementation that queries the db schema, processes the class mappings, and renders / executes the db access code as necessary.

---

Using an ORM will remove dependencies from your code on a particular SQL dialect. Instead of directly interacting with the database you'll be interacting with an abstraction layer that provides insulation between your code and the database implementation. Additionally, ORMs typically provide protection from SQL injection by constructing parameterized queries. Granted you could do this yourself, but it's nice to have the framework guarantee.

ORMs work in one of two ways: some discover the schema from an existing database -- the LINQToSQL designer does this --, others require you to map your class onto a table. In both cases, once the schema has been mapped, the ORM may be able to create (recreate) your database structure for you. DB permissions probably still need to be applied by hand or via custom SQL.

Typically, the credentials supplied programatically via the API or using a configuration file -- or both, defaults coming from a configuration file, but able to be override in code.

---

For a podcast that discusses ORM in detail see the following link. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed

---

While I agree with the accepted answer almost completely, I think it can be amended with lightweight alternatives in mind.

• If you have complex, hand-tuned SQL
• If your objects don't have any 1:1, 1:m or m:n relationships with other objects
• If you have a complex legacy schema that can't be refactored

...then you might benefit from a lightweight ORM where SQL is is not obscured or abstracted to the point where it is easier to write your own database integration.

These are a few of the many reasons why the developer team at my company decided that we needed to make a more flexible abstraction to reside on top of the JDBC.

There are many open source alternatives around that accomplish similar things, and jORM is our proposed solution.

I would recommend to evaluate a few of the strongest candidates before choosing a lightweight ORM. They are slightly different in their approach to abstract databases, but might look similar from a top down view.

• jORM
• ActiveJDBC
• ORMLite

---

my concern with ORM frameworks is probably the very thing that makes it attractive to lots of developers.

nameley that it obviates the need to 'care' about what's going on at the DB level. Most of the problems that we see during the day to day running of our apps are related to database problems. I worry slightly about a world that is 100% ORM that people won't know about what queries are hitting the database, or if they do, they are unsure about how to change them or optimize them.

{I realize this may be a contraversial answer :) }

참고URL : https://stackoverflow.com/questions/398134/what-are-the-advantages-of-using-an-orm