활성 기록의 목적은 무엇입니까?

StackOverflow https://stackoverflow.com/questions/1404405

문제

나는 CodeIgniter와 함께 땜질하고 있으며 처음으로 활발한 기록을 발견했습니다. 처음에 나는 SQL을 쓰는 법을 실제로 모르는 사람들을 위해 그것을 기각했습니다. 나는 내 분석이 결함이 있었고, 특히 레일에서 활발한 기록이 꽤 두드러 졌다는 것을 알고 있습니다.

그러나 활성 기록은 어떤 목적으로 유지됩니까? 다른 RDBMS 개성에서 멀리 떨어져있는 것입니까? 그렇다면 나는 그것이 SQL이 무엇을 의미하는지가 아니라고 생각했습니다. 또한 모범 사례는 무엇입니까?

미리 감사드립니다

도움이 되었습니까?

해결책

"활성 레코드 패턴"은 대부분의 프로그래밍 프레임 워크의 핵심 부분이되고 있습니다. 더 간단한 CRUD (생성, 업데이트, 읽기, 삭제) 작업을 더 빠르게 달성 할 수 있습니다. 예를 들어 많은 일반적이고 간단한 데이터 객체를 삽입, 업데이트 및 삭제하기 위해 많은 SQL을 작성하지 않고 값을 데이터 객체에 간단히 지정하고 명령을 실행할 수 있습니다. eg $ object-> save (), SQL은 당신을 위해 편집되고 실행되었습니다.

대부분의 프레임 워크는 또한 각 활성 레코드 모델 내에서 데이터 관계를 구현하여 객체와 관련된 데이터 액세스를 크게 단순화 할 수 있습니다. 예를 들어, CodeIgniter에서 카테고리에 "많은"제품이 있다고 지정하면 데이터베이스에서 카테고리 객체를로드 한 후 간단한 코드 라인으로 하위 제품을 나열 할 수 있습니다.

foreach ($category->products as $product) {
  echo $product->name;
}

Active Record의 또 다른 이점은 말한 것처럼 코드가 다른 데이터베이스 플랫폼에 쉽게 휴대 할 수있게한다는 것입니다 (사용중인 프레임 워크가 선택한 데이터베이스에 드라이버가있는 한). 이제 응용 프로그램이 인기를 얻으면 나중에 더 큰 가치가 있습니다!

바라건대 이것은 도움이되었을 것입니다. Wikipedia는 활성 기록을 잘 설명합니다 (http://en.wikipedia.org/wiki/active_record_pattern)) 그리고 Codeigniter 문서가 well을 것입니다. 개인적으로 나는 kohanaphp를 사용합니다.http://www.kohanaphp.com) CodeIgniter의 포크 유일한 포크이며 ORM 모델이 매우 유용하다는 것을 알았습니다!

다른 팁

Active Record는 데이터 액세스를위한 설계 패턴입니다 ...

현재 데이터 액세스와 관련하여 만나는 두 가지 주요 설계 패턴이 있습니다 : Activerecord 및 Repository 패턴

활성 기록

객체에는 상태를 DB (또는 기타 지속 메커니즘)로 유지하는 방법이 포함되어 있습니다.

고객 개체가있을 수 있습니다.

고객 객체는 customer.save ();, customer.get (int id)와 같은 많은 방법이 있습니다. 다른 사람.

이러한 방법은 실제로 실제 세계의 고객과 관련이 없습니다. 그들은 실제로 당신의 응용 프로그램의 인프라에 관한 것입니다.

저장소 패턴

저장소 패턴에서 고객 객체는 POCO 또는 멍청한 객체입니다. 고객을 대표하는 데 필요한 방법과 속성 만 있습니다 (이름, 이메일 주소, 목록 주문 등).

고객을 지속하려면 고객을 저장소에 전달합니다.

저장소 .Save (MyCustomer).

활성 레코드 패턴은 빠르고 작업하기 쉽습니다. 불행히도, 그것은 실제로 고객과 관련이없는 이러한 방법으로 도메인 모델을 혼란스럽게합니다. 따라서 시간이 지남에 따라 도메인 모델을 유지하기가 약간 어렵습니다.

많은 상황에서 활성 레코드 패턴을 사용하는 것이 매우 적절합니다. 예를 들어 - 아마도 크게 변하지 않을 상당히 간단한 앱을 작성한다면 아마도 Subsonic을 발사하고 내 활성 레코드 DAL을 생성 할 것입니다. 20 분 이내에 비즈니스 코드를 코딩하고 있으며 모든 DB 제품은 이미 처리되었습니다.

반면에, 나는 변화에 대한 감수성이 높은 특히 복잡한 도메인을 모델링하고 있다면, 도메인 모델을 깨끗하게 유지하고 nhibernate 또는 이와 유사한 저장소 패턴을 구현하고 싶습니다 ...

ado.net을 사용하여 자체 데이터 액세스를 출시 한 지 오랜 시간이 지났으며 실제로 권장하지는 않습니다.

나는이 패턴에 대한 내 자신의 견해를 줄 수 있지만 활성 기록 (그리고 다른 많은 사람들)의 가장 좋은 범위는 다음과 같습니다. 엔터프라이즈 애플리케이션 아키텍처 패턴 Martin Fowler.

10 장에서 :

활성 기록

데이터베이스 테이블 또는보기에 행을 줄이고 데이터베이스 액세스를 캡슐화하고 해당 데이터에 도메인 로직을 추가하는 객체.

객체는 데이터와 동작을 모두 가지고 있습니다. 이 데이터의 대부분은 지속적이며 데이터베이스에 저장해야합니다. Active Record는 가장 명백한 접근법을 사용하여 도메인 객체에 데이터 액세스 로직을 넣습니다. 이런 식으로 모든 사람들은 데이터베이스에 데이터를 읽고 쓰는 방법을 알고 있습니다.

...

그것을 사용하는시기

Active Record는 생성, 읽기, 업데이트 및 삭제와 같이 너무 복잡하지 않은 도메인 로직에 적합한 선택입니다. 단일 레코드를 기반으로 한 파생 및 검증은이 구조에서 잘 작동합니다.

...

활성 레코드는 단순성의 주요 이점이 있습니다. 활성 레코드를 쉽게 구축하고 이해하기 쉽습니다. 그들의 주요 문제는 활성 레코드 개체가 데이터베이스 테이블에 직접 해당하는 경우에만 잘 작동한다는 것입니다.

비즈니스 로직이 복잡하다면 곧 객체의 직접적인 관계, 컬렉션, 상속 등을 사용하고 싶을 것입니다. 이것들은 액티브 레코드에 쉽게 매핑되지 않으며, 단편적인 추가는 매우 지저분 해집니다. 그것이 당신이 대신 데이터 맵퍼를 사용하게 할 것입니다.

무엇이든, 그것은 쿼리를 더 쉽게 작성할 수 있습니다. 나는 정상적인 MySQL 구문이 구문 오류가 발생하기 쉽다는 것을 알게되며 (고유 한 오류가 아니라 내 고유 한) CI 활성 레코드 구문으로 거의 나에게는 거의 일어나지 않습니다.

Active Record는 CI IMHO에서 가장 멋진 기능 중 하나입니다.

활성 레코드는 ORM입니다. 객체 관련 매핑 기술을 살펴 보셨습니까? 나는 당신이 ORM을 이해한다면, 당신은 혜택을보기 시작할 것이라고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top