구성 요소를 TDataSets 자체에 직접 연결하는 대신 데이터 바인딩 된 구성 요소와 실제 기본 TDataSets 사이의 중개자로서 TDataSource를 만드는 추론은 무엇 이었습니까?왜 원래 TDataSource가 생성 되었습니까?
이것은 어리석은 질문처럼 보일지 모르지만 일반적인 "데이터 커넥터"구성 요소 등에 연결되는 광범위한 "데이터 뷰어"구성 요소에 대해 작업하고 있습니다. 이 컴포넌트 세트를 설계 할 때, 저는 고전적인 Delphi "TDataSet -> TDataSource -> 데이터 바인딩 컴포넌트"구조의 구조를 참조하고 있습니다. 그러나 내 구성 요소 세트에서 "TDataSource"및 "TDataSet"등가물의 기능을 본질적으로 단일 클래스로 병합하려고합니다. 그것은 처음에 그들을 분리하는 이유에 대해 궁금해했습니다.
약 decoupling 및 indirection입니다.
그리고 TDataSource와
두 그 종류가있다 : 마스터 세부 관계 (TDataSource 바인딩중인 TDataSets 같은 모듈에 디커플링때문에, 당신은 신속하게 한 TDataSource.DataSet 속성을 틀지에 의해 사용 기초하는 TDataSet의 전환 할 수 있습니다.
정확히 이것이 개발자 팀의 생각인지는 모르겠지만 데이터 세트를 변경하는 것이 도움이 될 수 있습니다. 전체 데이터 인식 컨트롤을 가지고 있고 모두 하나의 데이터 셋에 바인딩되어 있고 다른 컨트롤로 전환하려고한다고 가정 해 보겠습니다. 모든 매개 변수가 중개자를 통해 바인딩되는 경우 모든 컨트롤을 반복하고 해당 속성을 변경하는 대신 데이터 소스의 .Dataset 속성을 변경하면됩니다. (당신은 아직도 일이 설정된 방법에 따라, 필드 이름의 무리를 변경해야 할 수도 있습니다, 그래서 이것은 최선의 예를하지 않을 수도 있지만.)
을
는 는 는는 그래서 데이터 인식 컨트롤이 될 수 있다고 생각 각 컨트롤의 데이터 세트를 변경하지 않고 관련 데이터 소스가 가리키는 데이터 세트 만 변경하여 다른 데이터 세트에 첨부 할 수 있습니다.
그래서, 당신은 단지
이 두 가지가, 데이터베이스 구성 요소를 사용하는 것으로, 특정 사용자 인터페이스 인프라에 대한 종속성을 얻는다 결합합니다. 이러한 종류의 종속성은 사용자 자신의 프로그램에서는 좋지만 많은 개발자에게 배포되는 API에서는 좋지 않습니다.
당신은 어떤 종류의 모델 -보기 - 컨트롤러 패턴으로 생각할 수 있습니다.
데이터는 누가 데이터를 사용하고 무엇을 모르고 있는지를 모르는 데이터 세트 (모델)에 있습니다.
DB 인식 구성 요소는 누가 사용자를 보유하고 있는지 알지 못해도 이러한 데이터와 상호 작용할 수있는 다양한 인터페이스 (보기)를 제공합니다.
DataSource는 링크를 제공하고 모델 또는 뷰에 데이터 변경 또는 명령을 전달하는 컨트롤러 (컨트롤러) 사이에 있습니다.
이렇게하면보기를 건드리지 않고도 데이터 세트에 쉽게 바인딩 할 수 있으며, 데이터 세트를 고려하지 않고도 새보기를 변경하거나 추가 할 수 있습니다.
초기 버전에서는 다른 데이터베이스에 구성 요소를 부착하는 것이 거의 불가능했습니다. 사용할 각기 다른 데이터베이스에 대한 각 구성 요소의 버전이 필요했기 때문에 새 데이터베이스를 가져 오는 데 어려움이있었습니다. 소스에서 링크를 분리하면 쉽게 전환 할 수 있습니다. 또한 데이터베이스는 런타임 전용 프로그래밍 소스 일 수도 있습니다. – mj2008