35-2.마법사의 코드

35-2-1.스키마 파일

이 절에서는 마법사가 작성한 소스를 분석해 보자. 마법사가 프로젝트에 무슨 짓거리를 해 놓았는지 연구해 보면 ADO.NET의 큰 구조를 구경해 볼 수 있고 이후 코드를 어떤 식으로 변형할 수 있는지도 감잡을 수 있다. 외형상으로는 데이터 소스창에 마법사로 추가한 테이블이 표시되어 있고 솔루션 탐색기에 데이터 소스에 대한 스키마 파일과 그 부속 파일이 추가된다.

솔루션 탐색기의 ADOTestDataSet.xsd 파일이 방금 추가한 데이터 소스의 스키마 파일이며 이 파일에 데이터 소스의 구조가 기록되어 있다. XSD 파일을 더블클릭하면 데이터 집합 디자이너가 열리며 마법사가 만든 데이터 집합을 편집할 수 있다. 디자이너의 사용 방법은 다음 장에서 따로 알아보기로 한다. 일단은 XSD 스키마 파일이 어떻게 생겼는지 메모장으로 열어 보자.

대충 훓어 보면 어떤 정보를 정의하는지 짐작할 수 있다. 테이블 이름과 연결 문자열, 테이블로부터 데이터를 가져오는 쿼리문, 쿼리문과 연결되는 파라미터 등이 정의되어 있다. 이 파일은 데이터 소스의 스키마를 XML로 정의한 것이며 마법사는 연결한 데이터베이스에 대한 모든 정보를 이 파일에 기록한다.

C# 소스에서 XML 파일을 통해 데이터를 바로 액세스할 수 없으며 스키마 구조를 래핑하는 클래스를 정의해야 한다. 이 변환을 하는 유틸리티가 XSD.EXE이다. 과연 그런지 명령행으로 나가 테스트해 보자. 시작 메뉴에서 비주얼 스튜디오 명령 프롬프트를 선택하면 패스가 걸려 바로 테스트할 수 있다. DSWizard 프로젝트 폴더로 이동한 후 다음 명령을 실행해 보자.

 

copy ADOTestDataSet.xsd Temp.xsd

xsd /d Temp.xsd

 

원본 파일을 유지하기 위해 임시 파일로 복사하고 xsd 유틸리티로 컴파일하면 Temp.cs 파일이 만들어진다. 이 파일을 메모장으로 열어 보면 컴파일 가능한 C# 클래스가 정의되어 있다. XSD.EXE의 /l 스위치를 사용하면 C# 뿐만 아니라 다른 언어로도 변환할 수 있다. 닷넷이 언어에 독립적인 개발툴인 만큼 다양한 언어를 지원한다.

 

xsd /d /l:VB Temp.xsd

xsd /d /l:JS Temp.xsd

xsd /d /l:CPP Temp.xsd

 

이 명령에 의해 Temp.vb, Temp.js, Temp.h 등의 파일이 생성된다. 각 파일을 열어 보면 언어별로 생성된 클래스를 구경할 수 있다. 마법사는 XSD.EXE를 호출하여 C# 소스를 생성하고 프로젝트에 추가하는 과정까지 자동으로 수행한다. 그래서 ADOTestDataSet.xsd 파일로부터 ADOTestDataSet.Designer.cs 파일이 생성되며 이 파일이 분석 대상이다. 이 파일에 작성된 코드에 의해 테이블이 읽혀진다.

35-2-2.소스 분석

디자이너가 생성한 CS 소스 파일에는 데이터 소스를 액세스하는 C# 클래스가 정의되어 있다. 1500줄 가량 되는데 그나마 테이블이 극단적으로 단순해 이 정도지 조금 복잡한 테이블을 몇 개만 읽으면 만줄을 넘어가는 것은 일도 아니다.

각종 어트리뷰트와 예외 처리 구문, XML 주석 등이 죄다 포함되어 있어 구조가 복잡하며 현기증이 날 정도다. 사람을 위해 만든 코드가 아니다 보니 가독성은 고려하지 않았다. 다행히 지금 당장 이 코드를 모두 이해할 필요는 없지만 어떤 클래스가 정의되어 있는지와 대충의 구조는 파악할 필요가 있다. CS 파일에는 두 개의 네임스페이스와 다음 다섯 개의 주요 클래스가 정의되어 있다.

 

클래스

기반 클래스

설명

ADOTestDataSet

DataSet

데이터베이스

tblPeopleDataTable

DataTable

테이블

tblPeopleRow

DataRow

레코드

tblPeopleAdapter

Component

연결 및 명령

TableAdapterManager

Component

계층적 업데이트 지원

 

데이터 집합안에 테이블이 포함되어 있고 테이블안에 열과 행이 포함되어 있어 메모리상의 데이터베이스 역할을 한다. 어댑터 안에 연결과 명령 객체가 포함되어 있어 서버로의 연결과 명령 처리를 담당한다. 이 클래스가 협조적으로 동작하여 응용 프로그램이 실행된다. ADO.NET을 제대로 활용하려면 마법사가 생성한 클래스의 코드를 이해해야 하며 그러기 위해 기반 클래스에 대한 기본적인 정의와 기능에 대해 연구해야 한다.

디자이너가 만든 CS 파일을 열어 놓고 처음부터 순서대로 주요 부분을 구경해 보자. 단, 마법사가 만든 코드는 어트리뷰트가 덕지 덕지 붙어 있고 모든 클래스에 네임스페이스가 지정되어 있어 정신 사납다. 멤버마다 붙어 있는 this. 소속은 삭제하고 네임스페이스 지정도 생략하여 간략하게 표기하기로 한다. System.Data.DataSet 을 DataSet으로 표기한다는 뜻이다. 또 모든 멤버를 다 나열하지 않고 중요한 몇 가지 멤버만 분석해 본다.

데이터 집합

데이터 집합 클래스인 ADOTestDataSet은 다음과 같이 선언되어 있다. 형식적인 것과 중요하지 않은 내용은 걷어 내고 핵심 코드만 간추리는 대신 한글로 주석을 달아 두었다.

 

public partial class ADOTestDataSet : DataSet {

 

         // 내부에 포함된 테이블 객체

         private tblPeopleDataTable tabletblPeople;

 

         // 생성자

         public ADOTestDataSet() {

                      InitClass();

         }

 

         // 클래스 초기화

         private void InitClass() {

                      DataSetName = "ADOTestDataSet";

                      tabletblPeople = new tblPeopleDataTable();

                      base.Tables.Add(this.tabletblPeople);

         }

 

         // 내부 포함 테이블을 리턴하는 프로퍼티

         public tblPeopleDataTable tblPeople {

                      get {

                                   return tabletblPeople;

                      }

         }

         ....

 

선언문에서 보다시피 ADOTestDataSet 클래스는 닷넷 프레임워크의 DataSet 클래스로부터 파생된다. 그래서 DataSet의 모든 기능을 상속받으며 그 중 일부는 재정의하고 더 필요한 추가적인 처리까지 구현한다. 이 안에 테이블 객체가 포함되어 있고 테이블 객체를 리턴하는 프로퍼티도 선언되어 있어 객체.tblPeople로 테이블을 액세스할 수 있다.

생성자에서는 InitClass를 호출하며 이 메서드에서 데이터 집합의 프로퍼티를 초기화하고 테이블 객체를 생성하여 Tables 컬렉션에 추가한다. 예제에서는 테이블이 하나밖에 없어 InitClass의 코드가 단순하지만 여러 개의 테이블이 있다면 관계까지 생성하여 추가한다. 데이터 집합이란 테이블과 관계의 집합이므로 스키마에 정의된 모든 객체가 포함되어야 한다.

테이블 클래스

tblPeopleDataTable 클래스는 tblPeople 테이블을 정의한다. 테이블마다 래핑 클래스를 하나씩 생성한다. 데이터 집합에 포함되는 테이블이므로 ADOTestDataSet에 중첩 클래스로 선언되어 있다.

 

public partial class tblPeopleDataTable : DataTable, IEnumerable {

 

         // 테이블에 속한 열

         private DataColumn columnName;

         private DataColumn columnAge;

         private DataColumn columnMale;

 

         // 생성자

         public tblPeopleDataTable() {

                      this.TableName = "tblPeople";

                      this.InitClass();

         }

 

         // 클래스 초기화

         private void InitClass() {

                      columnName = new DataColumn("Name", typeof(string), null, MappingType.Element);

                      base.Columns.Add(this.columnName);

                      columnAge = new DataColumn("Age", typeof(int), null, MappingType.Element);

                      base.Columns.Add(this.columnAge);

                      columnMale = new DataColumn("Male", typeof(bool), null, MappingType.Element);

                      base.Columns.Add(this.columnMale);

                      Constraints.Add(new UniqueConstraint("Constraint1", new DataColumn[] {

                                                                           columnName}, true));

                      columnName.AllowDBNull = false;

                      columnName.Unique = true;

                      columnName.MaxLength = 10;

                      columnAge.AllowDBNull = false;

                      columnMale.AllowDBNull = false;

         }

 

         // 테이블의 열을 리턴하는 프로퍼티

         public DataColumn NameColumn {

                      get {

                                   return this.columnName;

                      }

         }

         ....

 

tblPeopleDataTable은 DataTable로부터 파생되므로 닷넷 프레임워크의 테이블 기능을 그대로 물려 받는다. 테이블을 구성하는 열은 필드 멤버로 선언되는데 열의 종류는 스키마로부터 추출한 것이다. tblPeople의 Name, Age, Male 세 개의 컬럼이 DataColumn 타입의 필드로 선언되었으며 각 컬럼을 리턴하는 프로퍼티도 정의되어 있다.

생성자는 테이블의 이름을 스키마 이름대로 대입하고 InitClass를 호출하여 테이블을 초기화한다. InitClass에서 테이블의 구조에 맞게 열 객체를 생성한다. 컬럼별로 DataColumn 생성자를 호출하여 이름과 타입을 정의하고 Columns 컬렉션에 추가하며 각 컬럼의 널 허용, 최대 길이, 고유값 속성도 스키마대로 정의한다. 앞 장에서 만들어본 MakeTable 예제와 유사해 이해하기 쉽다. 여기까지 생성된 데이터 집합을 그려 보자.

DataSet, DataTable로부터 파생된 객체여서 기능상 조금 확장되어 있을 뿐이지 전체적인 구조는 원론을 벗어나지 않음을 알 수 있다.

행 클래스

테이블의 각 행에 대한 클래스도 따로 선언되어 있다. 테이블과 마찬가지로 데이터 집합에 포함되는 것이므로 중첩 클래스로 선언되어 있다. 행은 열의 집합일 뿐이므로 구조가 비교적 간단하다.

 

public partial class tblPeopleRow : DataRow {

 

         // 행을 포함하는 테이블 참조자.

         private tblPeopleDataTable tabletblPeople;

        

         // 생성자에서 참조자 초기화

         internal tblPeopleRow(DataRowBuilder rb) :

                                   base(rb) {

                      tabletblPeople = ((tblPeopleDataTable)(Table));

         }

 

         // 각 열을 리턴하는 프로퍼티

         public string Name {

                      get {

                                   return ((string)(this[this.tabletblPeople.NameColumn]));

                      }

                      set {

                                   this[this.tabletblPeople.NameColumn] = value;

                      }

         }

         ....

 

DataRow로부터 파생되며 소속된 테이블에 대한 참조자를 멤버로 가진다. 생성자는 소속 테이블의 참조자를 초기화하는데 internal로 선언되어 있어 외부에서 호출하지 못한다. 행을 구성하는 열은 소속 테이블의 열 필드를 읽어 리턴하는 프로퍼티로 정의한다. 열의 타입에 맞게 캐스팅되어 있어 타입 조작없이 바로 읽을 수 있다.

35-2-3.테이블 어댑터

좀 더 아래로 내려가 보면 TableAdapter 클래스가 선언되어 있다. 데이터 집합, 테이블, 행 클래스는 모두 비연결 상태에서 사용하는 것이어서 서버와 통신하려면 어댑터의 도움이 필요하다. 어댑터는 상기의 클래스와 기능적으로 확연하게 구분되고 구조도 복잡하므로 별도의 네임스페이스에 선언되어 있다.

테이블 어댑터는 닷넷 프레임워크의 DataAdapter 클래스에 대한 래퍼이다. 공급자별로 데이터 어댑터(SqlDataAdapter 등)가 따로 있고 마법사는 이를 래핑하는 테이블 어댑터를 제공한다. 테이블당 하나씩 테이블 어댑터가 생성되며 클래스 이름은 테이블명+TableAdapter 식으로 붙여진다. 이 예제의 경우 tblPeopleTableAdapter라는 이름을 가지는데 통칭하여 TableAdapter라고 부른다.

TableAdapter는 디자이너에 의해 생성되는 사용자 정의 클래스이며 닷넷 프레임워크의 구성 요소가 아니므로 레퍼런스를 아무리 뒤져도 나오지 않는다. 테이블 어댑터를 정의하는 소스를 보자.

 

public partial class tblPeopleTableAdapter : Component {

        

         // 포함된 객체들

         private SqlDataAdapter _adapter;

         private SqlConnection _connection;

         private SqlTransaction _transaction;

         private SqlCommand[] _commandCollection;

         private bool _clearBeforeFill;

 

         // 생성자

         public tblPeopleTableAdapter() {

                      this.ClearBeforeFill = true;

         }

 

         // 포함된 객체에 대한 프로퍼티 선언

         private SqlDataAdapter Adapter {

                      get {

                                   if ((this._adapter == null)) {

                                                 this.InitAdapter();

                                   }

                                   return this._adapter;

                      }

         }

        

         internal SqlConnection Connection {

                      get { ... }

                      set { ... }

         }

        

         internal SqlTransaction Transaction{

                      get { ... }

                      set { ... }

         }

 

         protected System.Data.SqlClient.SqlCommand[] CommandCollection {

                      get {

                                   if ((this._commandCollection == null)) {

                                                 this.InitCommandCollection();

                                   }

                                   return this._commandCollection;

                      }

         }

 

         public bool ClearBeforeFill {

                      get {

                                   return this._clearBeforeFill;

                      }

                      set {

                                   this._clearBeforeFill = value;

                      }

         }

 

         private void InitAdapter() {

                      _adapter = new SqlDataAdapter();

                      ....

                      _adapter.DeleteCommand = new SqlCommand();

                      _adapter.DeleteCommand.Connection = Connection;

                      _adapter.DeleteCommand.CommandText = "DELETE ...

                      ....

                      _adapter.InsertCommand.CommandText = "INSERT INTO ...

                      ....

                      _adapter.UpdateCommand.CommandText = "UPDATE ...

                      ....

         }

 

         private void InitConnection() {

                      _connection = new SqlConnection();

                      _connection.ConnectionString = Settings.Default.ADOTestConnectionString;

         }

 

         private void InitCommandCollection() {

                      _commandCollection = new System.Data.SqlClient.SqlCommand[1];

                      _commandCollection[0] = new System.Data.SqlClient.SqlCommand();

                      _commandCollection[0].Connection = this.Connection;

                      _commandCollection[0].CommandText = "SELECT Name, Age, Male FROM tblPeople";

                      _commandCollection[0].CommandType = CommandType.Text;

         }

 

         public virtual int Fill(ADOTestDataSet.tblPeopleDataTable dataTable) {

                      Adapter.SelectCommand = CommandCollection[0];

                      if ((ClearBeforeFill == true)) {

                                   dataTable.Clear();

                      }

                      int returnValue = Adapter.Fill(dataTable);

                      return returnValue;

         }

 

         public virtual ADOTestDataSet.tblPeopleDataTable GetData() {

                      Adapter.SelectCommand = CommandCollection[0];

                      tblPeopleDataTable dataTable = new tblPeopleDataTable();

                      Adapter.Fill(dataTable);

                      return dataTable;

         }

 

         public virtual int Update(ADOTestDataSet.tblPeopleDataTable dataTable) {

                      return Adapter.Update(dataTable);

         }

 

클래스 선언문에서 제일 눈여겨 볼 것은 기반 클래스가 Component로 되어 있다는 점이다. 데이터 어댑터로부터 상속받는 것이 아니라 멤버로 포함한다. 객체지향의 코드 재사용 기법은 상속, 포함 두 가지가 있는데 테이블 어댑터는 포함 기법을 쓴다. 데이터 어댑터의 모든 기능을 제공함은 물론이고 추가 메서드와 프로퍼티도 제공한다.

멤버 선언문을 보면 SqlDataAdapter 타입의 _adapter 멤버가 선언되어 있는데 이것이 포함 객체이다. 데이터 공급자가 OLE DB였다면 OleDbDataAdapter 타입으로 선언된다. 어댑터 외에도 연결과 명령 객체가 포함되어 있다. 결국 TableAdapter는 응용 프로그램과 데이터베이스간의 통신에 필요한 연결, 명령, 데이터 어댑터, 트랜잭션을 래핑하는 클래스이다.

ClearBeforeFill 이라는 고유의 추가 프로퍼티가 정의되어 있는데 이 프로퍼티는 Fill 메서드로 데이터 집합을 채우기 전에 기존의 데이터를 지울 것인가를 지정한다. 생성자에서 초기화한대로 디폴트는 true이되 false로 변경하여 추가 또는 병합할 수 있다. 이 프로퍼티 외에는 생성자가 특별한 초기화를 하지 않는데 주요 초기화는 모두 Init* 메서드에 작성되어 있다.

테이블에 포함된 객체는 공개된 프로퍼티로 제공된다. 대표적으로 Adapter 프로퍼티를 분석해 보자. 이 프로퍼티에는 get 접근자만 있고 set 접근자가 없는 읽기 전용이다. get 접근자에서 비공개 필드인 _adapter를 리턴하되 null이면 InitAdapter 메서드를 호출하여 초기화한다. 어댑터가 필요하기 전까지 초기화를 연기하여 기동 속도를 높인다. 나머지 Connection, CommandCollection 프로퍼티도 구조는 거의 동일하다.

포함된 객체의 초기화는 Init* 메서드가 담당한다. InitAdapter 메서드에서 데이터 어댑터를 생성하고 세 개의 명령을 초기화한다. 위 소스 리스트에는 간략하게 표시했는데 굉장히 긴 쿼리문과 파라미터를 정의하는 코드가 따라온다. 결국은 세 개의 쿼리문을 초기화하는 것 뿐이다. 어차피 기계가 쿼리문을 생성하는 것이므로 CommandBuilder는 사용하지 않는다.

InitConnection 메서드는 SqlConnection 객체를 생성하고 연결 문자열을 읽어들인다. 연결 문자열이 구성 파일에 저장되어 있으므로 구성 파일을 읽었는데 마법사에서 이 옵션을 선택하지 않았다면 연결 문자열이 하드 코딩된다. InitCommandCollection 메서드는 명령 컬렉션을 생성하되 첫 번째 명령으로 tblPeople의 모든 필드를 가져오는 SELECT문을 작성한다. 이후 쿼리 구성 마법사에서 쿼리문을 추가하면 이 컬렉션이 확장된다. 이상의 두 메서드도 InitAdapter와 마찬가지로 지연된 초기화 기법을 사용한다.

Fill, GetData, Update 메서드는 데이터 어댑터의 동일 메서드를 호출하는 중계 역할을 할 뿐이다. 다만 Fill 메서드에 ClearBeforeFill 프로퍼티를 적용하는 코드가 더 추가되어 있다. 테이블 어댑터의 연결 멤버에 의해 데이터 소스에 연결되고 Fill 메서드에 의해 테이블의 내용이 읽혀지며 Update 메서드에 의해 응용 프로그램이 편집한 결과를 데이터 소스로 다시 보낸다.

35-2-4.DbDirect 명령

테이블 어댑터는 앞에서 살펴본 메서드 외에도 3개의 메서드를 추가로 더 가질 수 있다. 코드 아래쪽을 보면 Insert, Delete, Update 세 개의 메서드가 정의되어 있는데 DB에 바로 쿼리 명령을 날린다. 옵션이므로 생성될 수도 있고 아닐 수도 있는데 마법사는 디폴트로 이 메서드를 생성한다. TableAdapter의 속성창에서 GenerateDbDirectMethods 프로퍼티를 false로 바꾸면 생성하지 않는다.

과연 그런지 테스트해 보자. 솔루션 탐색기에서 ADOTestDataSet.xsd 파일을 더블클릭하면 데이터 집합 디자이너라는 것이 열리며 데이터 집합내의 테이블이 그래픽으로 나타난다. 아래 그림은 tblPeople 테이블과 어댑터의 모습이다. 아래쪽의 테이블 어댑터를 선택해 놓고 속성창을 보면 테이블 어댑터의 프로퍼티 목록이 나타난다.

 

GenerateDBDirectMethods를 False로 바꾸어 보자. 그리고 다시 컴파일한 후 ADOTestDataSet.Designer.cs 파일을 열어 보면 세 개의 메서드가 깜쪽깥이 사라진다. 이 프로퍼티는 마법사에게 DB 직접 실행 메서드를 생성할 것인지를 지시한다. 객체 자체의 선언문에 있는 프로퍼티가 아니라 개발툴의 동작을 제어한다는 면에서 특이하다.

DBDirect 메서드는 데이터 소스에 직접 연결하여 명령을 실행한다. 대표적으로 Insert 메서드만 분석해 보자. 앞 장에서 관련 클래스를 제대로 공부했다면 이 메서드의 코드는 쉽게 분석된다. 약간의 주석을 달았으므로 읽어가며 분석해 보자.

 

public virtual int Insert(string Name, int Age, bool Male) {

         // 이름은 반드시 입력해야 한다.

         if ((Name == null)) {

                      throw new ArgumentNullException("Name");

         }

         else {

                      // 첫 번째 파라미터에 인수로 전달된 이름 대입

                      Adapter.InsertCommand.Parameters[0].Value = ((string)(Name));

         }

         // 두 번째, 세 번째 파라미터에 나이와 성별 대입

         Adapter.InsertCommand.Parameters[1].Value = ((int)(Age));

         Adapter.InsertCommand.Parameters[2].Value = ((bool)(Male));

 

         // 연결되어 있지 않으면 지금 연결한다.

         ConnectionState previousConnectionState = Adapter.InsertCommand.Connection.State;

         if (((Adapter.InsertCommand.Connection.State & ConnectionState.Open)

                                                 != ConnectionState.Open)) {

                      Adapter.InsertCommand.Connection.Open();

         }

         try {

                      // 쿼리문을 실행한다.

                      int returnValue = Adapter.InsertCommand.ExecuteNonQuery();

                      return returnValue;

         }

         finally {

                      // 연결을 해제한다.

                      if ((previousConnectionState == ConnectionState.Closed)) {

                                   Adapter.InsertCommand.Connection.Close();

                      }

         }

}

 

테이블 어댑터에 정의되어 있는 InsertCommand를 실행하되 이 쿼리문이 요구하는 세 개의 파라미터를 메서드의 인수로 전달받아 대입한다. tblPeople이 세 개의 필드로 구성되어 있으므로 Insert 메서드도 세 개의 인수를 받는다. 쿼리문 실행을 위한 연결도 자체적으로 관리한다. 이 메서드로 새 레코드를 삽입하려면 다음과 같이 호출한다.

 

tblPeopleTableAdapter.Insert("윤은혜", 24, true);

 

필드의 타입에 꼭 맞는 인수를 필드 개수만큼 받아 쿼리문을 실행한다. 이런 호출이 가능한 이유는 어댑터는 타입이 있기 때문이다. 좀 복잡한 얘기이므로 다음 절에서 상세하게 연구해 보자. 마지막으로 마법사가 폼에 작성한 코드를 분석해 보자. 디자이너가 만든 폼 파일에는 다음 멤버가 선언되어 있다.

 

partial class Form1 {

         ....

         private ADOTestDataSet aDOTestDataSet;

         private BindingSource tblPeopleBindingSource;

         private tblPeopleTableAdapter tblPeopleTableAdapter;

         private TableAdapterManager tableAdapterManager;

         private BindingNavigator tblPeopleBindingNavigator;

         ....

         private DataGridView tblPeopleDataGridView;

         ....

}

 

그리고 InitializeComponent 메서드에는 이 객체를 생성하고 초기화하는 코드가 작성되어 있다. Form1_Load 이벤트에서 어댑터의 Fill 메서드를 호출하여 데이터 집합을 채우며 데이터 집합의 내용은 그리드를 통해 사용자에게 보여지는 것이다.

35-2-5.계층적 업데이트

마법사가 생성한 마지막 클래스인 어댑터 매니저에 대해 간략하게 알아보자. 이 클래스는 참조 무결성을 지키는 계층적 업데이트(Hierarchical Update) 기능을 위해 추가된 것이다. 테이블 어댑터와 같은 네임스페이스에 정의되어 있으며 이름은 TableAdapterManager로 고정되어 있다.

단일 테이블은 저장할 때 행의 상태값을 참조하여 변경된 행만 적절한 쿼리문을 실행하면 된다. 관계가 있는 복수 테이블은 저장 순서에 유의해야 하는데 부모 테이블을 먼저 저장해야 자식 테이블을 저장할 수 있다. tblPeople과 tblSale의 경우 양쪽에 새 행이 추가되었다면 고객 레코드를 먼저 삽입하고 구입 내역을 삽입해야 한다. 그렇지 않으면 구입 내역이 먼저 저장되어 일시적으로 무결성이 깨지며 이 짧은 순간에도 예외가 발생한다.

그래서 관계가 설정된 테이블은 순서에 맞게 저장 및 수정해야 하는데 이 귀찮은 작업을 대신해 주는 것이 어댑터 매니저이다. 어댑터 매니저는 관계의 정보를 참조하여 순서에 맞게 업데이트 명령을 실행함으로써 저장중에도 무결성을 유지한다. 이런 기능을 계층적 업데이트라고 한다. 개념이 간단하지만 왜 이런 기능이 필요한지 예제를 만들어 테스트해 보자.

 

HiUpdate

 

HiUpdate 프로젝트를 생성한 후 데이터 소스 마법사를 실행하여 ADOTest 데이터베이스에 있는 두 개의 테이블을 모두 읽어온다.

테이블이 하나 더 늘어나면 마법사가 생성하는 코드도 거의 두 배로 늘어난다. 테이블당 어댑터와 행 레코드가 하나씩 생성되기 때문이다. 데이터 소스창을 보면 두 개의 테이블이 나란히 등록되어 있다. 데이터 소스창에서 tblPeople 테이블을 폼으로 드래그해 보자.

폼에는 그리드와 네비게이터가 나타나고 트레이에는 어댑터 매니저도 배치된다. 다음으로 tblSale 테이블을 폼으로 드래그하여 그리드로 출력한다. 그리고 테스트를 위한 버튼 하나를 btnUpdate라는 이름으로 배치하고 두 테이블을 저장하는 코드를 작성한다.

 

private void btnUpdate_Click(object sender, EventArgs e) {

         tblPeopleTableAdapter.Update(aDOTestDataSet.tblPeople);

         tblSaleTableAdapter.Update(aDOTestDataSet.tblSale);

}

 

테이블마다 어댑터가 따로 생성되므로 각 어댑터의 Update 메서드만 호출하면 된다. 이 상태에서 실행해 보면 두 개의 테이블이 동시에 보인다.

 

각각의 그리드에서 두 테이블을 개별적으로 편집할 수 있되 단, 두 테이블은 외래키 제약을 어기지 않는 범위에서만 편집해야 한다. 김태희를 지워 버린다거나 정우성의 이름을 바꾼 상태에서 저장하면 외래키 제약을 어겼다는 예외가 발생한다. 22세의 박신양 청년이 파리채를 구입한 것으로 기록해 보자.

고객 그리드에 박신양을 입력하고 구입 내역 그리드에 파리채를 기록했다. 구입 내역 테이블의 박신양이 고객 테이블에 먼저 삽입되었으므로 무결성에 문제가 없다. Update 버튼을 누르면 두 테이블이 순서대로 잘 저장된다. 그러나 저장 순서를 바꾸면 예외가 발생한다.

 

private void btnUpdate_Click(object sender, EventArgs e) {

         tblSaleTableAdapter.Update(aDOTestDataSet.tblSale);

         tblPeopleTableAdapter.Update(aDOTestDataSet.tblPeople);

}

 

이 코드에서 예외가 발생하는 이유는 구입 내역 테이블에 파리채를 삽입할 시점에는 박신양이 존재하지 않기 때문이다. 물론 잠시 후에 tblPeople을 저장하면 완전한 데이터가 되겠지만 일시적으로나마 무결성이 깨졌기 때문에 서버는 예외를 발생시키고 이 저장을 허락하지 않는다. 문제를 해결하려면 부모 테이블을 먼저 저장하고 자식 테이블을 저장해야 한다. 저장 순서를 원래대로 바꾸면 문제는 해결된다.

그러나 아직 문제가 있다. 원래 코드로 바꾼 상태에서 이번에는 박신양 고객과 파리채 구입 내역을 삭제한 후 저장해 보자. 역시 똑같은 문제가 발생한다. 왜냐하면 부모 테이블의 고객이 먼저 삭제되고 구입 내역이 이어서 삭제되므로 일시적으로 무결성이 깨지는 똑같은 문제가 생기기 때문이다. 이때는 자식 테이블을 먼저 저장하고 부모 테이블을 나중에 저장해야 한다. 규칙은 아주 간단한데 일시적으로나마 관계를 위반하는 레코드가 없도록 저장 순서를 잘 조정하면 된다.

관계를 구성하는 테이블이 두 개 뿐이라면 어찌 어찌 순서만 잘 조정하면 되겠지만 여러 개의 테이블이 복잡한 관계를 이루고 있고 삽입 뿐만 아니라 수정이나 삭제도 같이 고려하자면 정확한 순서를 잡기 어렵다. 사용자의 조작 순서대로 명령을 수행하면 되지만 상당히 귀찮은 일임은 분명하다. 이런 작업을 대신해 주는 것이 바로 어댑터 매니저이다. 매니저의 UpdateAll 메서드를 호출하면 모든 것이 순서에 맞게 처리된다.

 

private void btnUpdate_Click(object sender, EventArgs e) {

         this.tableAdapterManager.UpdateAll(this.aDOTestDataSet);

}

 

이 코드는 이미 네비게이터의 저장 버튼에 작성되어 있다. 유효성 점검과 편집중인 레코드의 편집 종료까지 처리되어 있어 편집한 모든 레코드가 잘 저장된다.

 

private void tblPeopleBindingNavigatorSaveItem_Click(object sender, EventArgs e) {

         this.Validate();

         this.tblPeopleBindingSource.EndEdit();

         this.tableAdapterManager.UpdateAll(this.aDOTestDataSet);

}

 

그렇다면 어댑터 매니저는 과연 어떻게 작성되어 있는지 디자이너가 만든 소스 파일을 보자. 어댑터 클래스 다음에 다음과 같이 선언된 클래스를 볼 수 있다.

 

public partial class TableAdapterManager : global::System.ComponentModel.Component {

         private UpdateOrderOption _updateOrder;

         private tblPeopleTableAdapter _tblPeopleTableAdapter;

         private tblSaleTableAdapter _tblSaleTableAdapter;

         private bool _backupDataSetBeforeUpdate;

         private global::System.Data.IDbConnection _connection;

 

         public virtual int UpdateAll(ADOTestDataSet dataSet) {

                      ....

         }

 

Component로부터 파생되는 TableAdapterManager 클래스이며 이 안에 각 테이블의 어댑터와 연결이 멤버로 포함되어 있고 계층적 업데이트를 수행하는 UpdateAll 메서드도 정의되어 있다. UpdateAll 메서드의 실제 코드는 디자이너가 만든 소스 파일에서 볼 수 있는데 트랜잭션으로 모든 업데이트를 감싸며 변경된 행을 수집하고 스키마 정보를 참조하여 순서에 맞게 호출한다.

마법사의 코드를 읽어 보면 대충 어떤 식으로 동작한다는 것을 알 수 있어 자세한 소스 분석은 생략한다. 개요만 알고 있으면 굳이 내부 코드까지 들여다 볼 필요는 없다. 어댑터 매니저는 마법사가 생성하는 사용자 정의 클래스이므로 역시 레퍼런스에는 기록되어 있지 않다. 닷넷 프레임워크가 정의하는 클래스는 아니지만 데이터 집합 디자이너를 통해 두 개의 프로퍼티를 디자인 타임에 편집할 수 있다.

 

l BackupDataSetBeforeUpdate : 저장할 때 트랜잭션 대신 백업을 사용할 것인가를 지정한다. 디폴트는 false여서 트랜잭션을 쓰며 롤백하면 중간에 에러가 발생해도 원래대로 돌릴 수 있다. 그러나 트랜잭션만으로 깔끔하게 원상 복구가 되지 않는 경우가 있는데 대표적인 경우가 자동 증가열이다. 삽입한 후 취소하더라도 계속 증가하도록 되어 있어 롤백만으로는 증가값까지 복원할 수 없는데 이런 경우 트랜잭션 대신 업데이트 전에 전체 데이터 집합을 백업해 놓고 실패시 백업으로 복원한다.

l UpdateOrder : Insert, Update, Delete 명령의 실행 순서를 결정한다. Delete는 항상 제일 끝이며 주로 Insert와 Update의 순서를 통제하는데 디폴트는 Insert 명령을 먼저 실행하는 것으로 되어 있다. 위 예제처럼 레코드를 삽입만 하는 경우에는 순서에 큰 의미가 없지만 레코드의 기본키를 업데이트하고 업데이트된 값을 참조하는 레코드를 삽입하는 경우라면 Update를 먼저 처리해야 한다.

 

데이터 집합에 HierarchicalUpdate 프로퍼티가 있어 이 기능을 사용할 것인지 여부를 선택할 수 있다. 마법사가 만든 코드는 디폴트로 이 기능을 사용하는데 관계가 복잡하지 않거나 수작업으로 순서를 조정할 수 있다면 계층적 업데이트 기능을 제거할 수도 있다.