Delphi 데이터 인식 구성 요소 사용 - 장단점

Delphi 데이터 인식 구성 요소 사용 - 장단점

닫혔습니다. 이 질문은.여론에 입각한현재 답변을 수락하고 있지 않습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트합니다.

7년 전에 문을 닫았습니다.

이 질문을 개선합니다.

프로젝트에서 데이터 인식 구성 요소를 사용하는 것에 대한 당신의 의견을 알고 싶습니다.Delphi 및 데이터 인식 구성요소(Delphi의 표준 제품군 또는 타사 제품)를 사용하여 애플리케이션(win32 및 웹)을 개발할 때의 '장점'과 '약점'은 무엇입니까?

저는 FireBird를 사용하여 성숙한 구성요소 모음인 IBObjects와 많은 작업을 했고 매우 잘 작동했습니다.

그러나 다른 RDBMS(MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, Paradox, Interbase, FireBird 등)도 많이 있습니다.데이터 인식 구성요소를 많이 사용한 대규모 프로젝트를 개발한 경우 데이터베이스 유형 및 데이터 인식 구성요소 제품군 이름으로 답변하십시오.

DB2(AS400)에도 관심이 있습니다.성공적으로 사용한 구성 요소는 무엇입니까? 또는 실제로 사용해야 하는 구성 요소는 무엇입니까?

데이터 인식 구성 요소를 사용하면 비즈니스 로직과 UI 로직을 명확하게 구분하지 않는 애플리케이션이 생성된다는 것을 알게 되었습니다.

이는 소규모 프로젝트에서는 문제가 없지만 규모가 커짐에 따라 코드의 유지보수가 점점 더 어려워집니다.

이벤트 코드의 모든 다양한 비트(및 그들의 상호 작용)는 이해하기에 정말 악몽이 될 수 있습니다.

항상 그런 경우에 저는 데이터 인식 구성 요소를 버리고 (핸드 코딩된) MVC 설계로 전환했습니다.

이를 위해서는 많은 사전 코딩 노력이 필요하지만 유지관리, 확장 및 디버깅이 가능한 프로젝트의 결과(IMHO)가 필요합니다.

Delphi 애플리케이션의 데이터 인식 및 비데이터 인식 방식을 모두 사용해 본 결과, 저는 요즘 다시 데이터 인식 구성 요소 캠프로 돌아왔습니다.코드를 올바르게 계층화하려면 약간의 작업과 규율이 필요하지만 데이터 인식 제어를 사용하지 않고 수동으로 모든 작업을 수행하는 것보다 여전히 빠릅니다.

데이터 인식 구성 요소 사용에 대한 몇 가지 팁은

• FishFact를 더 큰 규모로 다시 작성하지 마십시오.당신의 디자인에 대해 생각해 보세요.

• TData Module을 사용하지 말고 애플리케이션 데이터의 작은 부분만 담당하는 많은 TData Module을 사용하십시오.

• TD 데이터 세트는 TDataModules에 속해 있는 반면, TDataSources는 TForms에 속해 있습니다(마스터/세부 관계에 사용되지 않는 한).

• DataSnap TClientDataSet과 같은 메모리 내 데이터셋을 사용합니다.

• 클라이언트 데이터 세트가 데이터베이스 테이블을 정확하게 미러링할 필요는 없습니다.DataSnap을 사용하면 특정 용도에 맞게 조정된 데이터셋을 생성할 수 있도록 메모리의 데이터 구조를 마사지할 수 있습니다.특히 당신은 다음과 같은 것들을 할 수 있습니다.

  • 두 개 이상의 테이블을 하나의 편집 가능한 데이터 세트에 결합

  • 마스터 세부 테이블 구조를 정규화하지 않으면 UI 코드를 단순화할 수 있습니다.

  • 메모리 내 전용 필드 만들기(계산된 필드와 동일하지만 해당 필드에 쓸 수도 있음)

• TClientDataSet 중첩 테이블은 유용하지만 마스터 세부 정보 관계를 표현하는 유일한 방법은 아닙니다.때로는 TDataSource를 통해 두 개의 독립적인 TClientDataSet를 결합하여 기존 방식으로 작업을 수행하는 것이 좋습니다.

ORM 솔루션을 살펴봅니다.

다중 계층 아키텍처를 사용하는 좋은 접근 방식입니다.DELPI win32에 대한 ORM 참조

데이터 인식 제어는 훌륭하지만 비즈니스 코드를 별도의 계층에 저장해야 합니다.

그것은 어렵지 않지만, 당신은 그것을 할 수 있는 방법을 알아야 합니다.

한 가지 접근 방식은 데이터 모듈(또는 다른 비시각적 컨테이너)에 데이터 세트 구성 요소를 두는 것입니다.

또 다른 유용한 방법은 TClientDataSet을 사용하여 UI 항목을 수행하고 이를 UI와 비즈니스 계층 간의 중간 버퍼로 사용하는 것입니다.그런 다음 비즈니스 계층은 데이터 계층과 관련된 TDataSet 구성 요소를 사용합니다.

--조린

Delphi 데이터 인식 구성 요소는 사용 중인 백엔드 데이터베이스 엔진에 의존하지 않으므로 Firebird, MS SQL Server, Oracle 등을 사용해도 데이터 인식 구성 요소에 문제가 없습니다.이들은 자신에게 할당된 데이터 소스 구성요소만 알고 있으며 이를 통해 모든 DB 관련 작업을 수행합니다.

저를 위해, 데이터 인식 구성 요소로 좋은 방법으로 무언가를 할 수 있다면, 저는 그것들을 사용할 것입니다.이것들은 보통 짧은 시간 안에 이루어져야 하는 작은 프로젝트들입니다.더 큰 프로젝트에서는 데이터 인식 구성 요소를 완전히 배제하거나 데이터 프레젠테이션에만 사용되고 사용자 입력을 받지 않는 형태로 사용할 수 있습니다.사용자 입력을 받을 때 비데이터 인식 구성 요소를 사용할 수 있는데, 이는 비데이터 인식 구성 요소를 보다 유연하게 제어하고 입력을 검증할 수 있기 때문입니다.물론 데이터웨어 구성요소는 그러한 시나리오에서도 여전히 유용할 수 있습니다.OnBeforePost와 같은 데이터셋 이벤트에서 사용자 입력의 유효성을 확인할 수 있습니다.또한 다중 계층 설계를 사용하고 있고 클라이언트 앱이 데이터 발표자 계층을 나타내는 경우에는 입력 유효성 검사가 중간 계층에서 수행되므로 클라이언트 앱에서 데이터 인식 구성 요소를 사용하여 입력을 수신하고, 검증 및 추가 처리를 위해 중간 계층으로 전송할 수 있습니다.

데이터 인식 구성요소는 RAD 및 프로토타이핑 관점에서 특히 데이터를 기반으로 하는 보고서 또는 그리드를 설계할 때 유용합니다. 즉, 설계 시 수정할 수 있습니다.그래서 그렇게 사용합니다.하지만 배송 코드로 변환할 때가 되면 거의 항상 연결을 끊고 쿼리에서 SQL을 제거하고 코드로 모든 작업을 수행합니다.특히 버전 제어가 가능한 다중 개발자 환경에서는 훨씬 더 예측 가능하고 유지 관리가 가능합니다.SQL이 양식에 포함되어 있는 경우 SQL이 실제로 어디에 있는지 파악하는 것은 큰 문제입니다.특히 SQL이 두 곳에 있는 것은 좋지 않습니다. 그리고 나서 어떤 것이 효과가 있는지 알아내야 합니다.

Unidac은 Firebird(내가 사용하는)를 포함한 많은 데이터베이스 서버를 지원하고 매우 좋은 기능을 가지고 있습니다.

Remobject SDK와 결합하면 n계층 아키텍처와 데이터베이스 추상화의 멋진 조합을 얻을 수 있습니다.

언급URL : https://stackoverflow.com/questions/4722563/using-delphi-data-aware-components-pros-and-cons