34-2.데이터 집합 관리

34-2-1.동시성 문제

데이터 집합(DataSet)은 서버의 데이터를 가져와 편집된 내용을 정확하게 반영하여 서버로 재전송한다. 서버와 연결이 끊어진 상태라도 종료 직전에 동기화만 제대로 하면 문제가 없으며 비연결형으로 훌륭하게 동작한다. 그러나 비연결형의 이런 정확성은 혼자서 서버를 독차지할 때만 확보되며 여러 사용자가 서버의 데이터를 공유하면 문제가 생길 수 있다. 이것을 동시성 문제라고 하는데 어떤 문제가 있는지 테스트해 보자.

DataAdapterTest 예제에서 읽기 버튼을 누르면 어댑터에 의해 서버의 tblPeople 테이블의 내용이 읽혀지며 그리드에 출력된다. 이 상태에서 SQL 서버를 실행해 놓고 쿼리창에서 ADOTest DB에 접속해 보자. 쿼리창도 하나의 클라이언트이므로 한 서버에 두 명의 사용자가 동시에 접속한 것이다. SQL 서버를 실행하기 번거롭다면 DataAdapterTest 예제를 두 번 실행해도 효과는 같다.

그리드에서 배용준의 이름을 욘사마로 수정하면 별다른 문제없이 잘 수정된다. 클라이언트의 데이터 집합만 수정했을 뿐 아직 서버로는 전송하기 전이다. 이 상태에서 SQL 서버의 쿼리창으로 이동하여 다음 명령을 수행하여 배용준의 이름을 강준상으로 변경한다. 쿼리창은 연결형으로 동작하므로 즉시 레코드를 수정한다.

UPDATE tblPeople SET Name = '강준상' WHERE Name = '배용준';

이 상태에서 다시 예제로 돌아가 저장 버튼을 눌러 그리드에서 편집한 것을 서버로 전송해 보자. 다음 예외가 발생하며 제대로 저장되지 않는다.

왜 이런 문제가 발생하는지 클라이언트 코드의 동작을 추적해 보자. Update 메서드는 데이터 집합의 테이블을 순서대로 읽어 집된 레코드를 조사하며 배용준 레코드의 이름이 욘사마로 편집된 것을 발견하고 다음 쿼리문을 실행한다.

UPDATE tblPeople SET Name = '욘사마' WHERE Name = '배용준';

서버는 이 쿼리문을 실행할 수 없다. 왜냐하면 다른 사용자에 의해 배용준은 이미 사라져 버렸고 강준상만 남았기 때문이다. 다른 사용자의 편집으로 인해 서버의 데이터를 가져올 때와 현재 상황이 달라져 업데이트할 대상이 사라져 버렸다. 이것이 바로 동시성의 문제이다. 반대로 해도 마찬가지인데 예제에서 욘사마로 먼저 바꾸고 SQL 서버에서 강준상으로 바꾸어도 마찬가지 결과가 나온다.

데이터베이스는 원래 여러 사용자가 공유하는 것인데 비해 ADO.NET은 동시 접속에 대한 처리를 하지 못한다. ADO.NET은 낙관적 동시성 제어 정책을 사용하며 락을 걸지 않아 다른 사용자가 수정하는 것을 허락한다. 남들이 바꾸거나 말거나 낙관적으로 그냥 내버려 두는 것이며 그러다 보니 문제가 발생한다.

반대 개념은 비관적 동시성 제어라고 하는데 한 사용자가 데이터를 읽은 후 저장할 때까지 아무도 이 데이터를 쓸 수 없도록 락을 걸어 버리는 것이다. 쉽게 말해 "내가 사용중인 데이터는 아무도 못 건드려"하고 선포해 놓는 것이다. 락이 걸린 상태에서는 아무도 이 데이터를 쓸 수 없으므로 문제가 발생할 여지가 없다. 그러나 특정 데이터를 한명만 쓸 수 있어 동시성이 떨어지므로 짧은 시간동안만 락을 걸어야 한다.

ADO.NET의 비연결형 방식은 서버와의 연결이 완전히 끊긴 상태에서 동작하기 때문에 락을 걸 수 없으며 따라서 비관적 동시성 제어를 사용할 수 없다. 서버에 연결도 하지 않은 상태이므로 누가 뭘 어떻게 바꾸든 참견할 여지가 없고 그렇다 보니 사본을 편집하는 중에 다른 사용자가 원본을 마음대로 바꿔 버릴 수 있다. 그렇다면 동시성 문제에 대한 ADO.NET의 해결책은 무엇일까?

문제가 있다면 당연히 해결책도 있어야겠지만 안타깝게도 이 문제에 대해서는 해결책이 제공되지 않는다. 라이브러리는 문제가 발생했을 때 예외를 던지는 것 외에는 어떠한 조치도 취하지 않으며 사실 문제를 해결할 수 있는 뾰족한 방법도 없다. 서버에서 무슨 일이 일어나는지 모르는데 무슨 해결책이 있겠는가? 그래서 동시성 문제는 전적으로 응용 프로그램이 알아서 해결해야 한다. 예외를 받아 자신의 고유 논리에 맞게 처리하는 수밖에 없다. 위 문제의 경우 응용 프로그램이 취할 수 있는 해결책은 다음 두 가지 정도를 생각해 볼 수 있다.

l 우선은 예외가 발생한 문장을 무시해 버리는 것이다. 배용준이 없어져 버렸다면 이 레코드에 대한 업데이트를 실행하지 않는다. 이 방법대로라면 먼저 편집한 쪽의 값이 유지되며 배용준은 서버가 바꾼 강준상으로 남는다.

l 예외가 발생한 문장을 강제로 실행한다. 누군가가 배용준을 강준상으로 바꾸었다면 다시 욘사마로 바꾸어 버린다. 이렇게 하려면 원래 레코드를 찾을 수 있는 방법이 필요한데 기본키에 타임스탬프나 고유의 ID를 숨겨 두어야 한다.

이 외에 제 3 의 방법도 생각해 볼 수 있지만 어떤 방법을 쓰든 둘 중 하나의 업데이트가 손실되는 것은 어쩔 수 없다. 전후의 값 중 어떤 것을 인정하느냐의 차이가 있을 뿐이다. 정 문제가 된다면 예외 처리기에서 대화상자를 띄워 사용자에게 둘 중 어떤 값을 취할 것인지를 물어보는 수밖에 없다. 논리적으로 해결할 방법이 없으니 사용자에게 책임을 떠 넘기는 것이다. 다행히 예외로 전달되는 인수에는 예외의 원인에 대한 상세한 정보가 포함되어 있다.

이 문제는 비연결형의 단점이라기 보다는 사용 용도가 다른 것으로 이해해야 한다. 동시성 문제를 원천적으로 방지하려면 어쩔 수 없이 연결형을 사용해야 한다. 연결형은 수정할 때마다 락을 걸 수 있기 때문에 동시성 문제를 어느 정도 해결할 수 있다. 단, 연결형도 완전한 해결은 쉽지 않다. 극도의 일관성을 확보하려면 서버의 잠금 수준을 높여야 하는데 이렇게 되면 성능이 떨어진다.

동시성 문제를 완벽하게 해결하는 유일한 방법은 서버를 꽁꽁 숨겨두고 혼자 쓰는 것 밖에 없다. 그러나 데이터베이스란 원칙적으로 공유하는 것이고 공유에 의해 가치가 발휘되는 것이어서 혼자서 독점할 바에야 굳이 덩치 큰 데이터베이스를 쓸 이유가 없다. 동시성과 일관성 이 두 가지는 태생적으로 배타적 속성을 가져 양립할 수 없으며 고가의 상용 DBMS도 적당히 균형을 맞추어 타협함으로써 문제를 최소화할 뿐이다.

34-2-2.데이터 집합 병합

비연결형에서는 두 개 이상의 다른 사본이 존재할 수 있다. 두 명의 사용자가 서버의 데이터를 가져간 후 각자 나름대로 편집하면 두 개의 사본이 생성되는데 양쪽에서 데이터를 따로 저장하면 먼저 저장한 쪽의 데이터가 사라지는 동시성 문제가 발생한다. 이 문제를 완벽하게 해결할 수는 없지만 두 사본을 하나로 병합한 후 저장하면 완화할 수는있다.

병합 과정에서 둘 중 어느 값을 채택할 것인지 미리 타협하거나 정해진 규칙에 따라 한쪽에 우선권을 줄 수 있어 적어도 병합이 완료된 후에는 더 이상의 충돌이 발생하지 않는다. DataTable과 DataSet 클래스에 병합 메서드가 제공되는데 DataSet의 메서드 위주로 알아보자.

public void Merge (DataSet dataSet [,bool preserve,MissingSchemaAction Action])

public void Merge (DataTable table [,bool preserve,MissingSchemaAction Action])

public void Merge (DataRow[] rows [,bool preserve,MissingSchemaAction Action])

데이터 집합끼리 병합할 수도 있고 테이터 집합의 테이블 하나를 병합할 수도 있다. 테이블보다 더 작은 단위인 행의 집합을 병합하는 것도 가능하다. 다음 예제는 데이터 집합과 테이블을 병합한다.

MergeTest

using System; ~ using System.Windows.Forms;

namespace MergeTest {

public partial class Form1 : Form {

private SqlConnection Con;

private SqlDataAdapter Adpt;

private DataSet DbADOTest;

private DataTable tblPeople2;

public Form1() {

InitializeComponent();

}

private void btnMerge_Click(object sender, EventArgs e) {

Con = new SqlConnection();

Con.ConnectionString = "Server=(local);database=ADOTest;" +

"Integrated Security=true";

Adpt = new SqlDataAdapter("SELECT * FROM tblPeople", Con);

DbADOTest = new DataSet("ADOTest");

Adpt.Fill(DbADOTest, "tblPeople");

tblPeople2 = MakePeopleTable();

DbADOTest.Merge(tblPeople2);

dataGridView1.DataSource = DbADOTest.Tables["tblPeople"];

}

private DataTable MakePeopleTable() {

DataTable tblPeople = new DataTable("tblPeople");

DataColumn col;

DataRow row;

// 열 등록

col = new DataColumn("Name", typeof(String));

col.MaxLength = 10;

col.AllowDBNull = false;

col.Unique = true;

tblPeople.Columns.Add(col);

tblPeople.PrimaryKey = new DataColumn[] { col };

col = new DataColumn("Age", typeof(Int32));

col.AllowDBNull = false;

tblPeople.Columns.Add(col);

col = new DataColumn("Male", typeof(bool));

col.AllowDBNull = false;

tblPeople.Columns.Add(col);

// 행 삽입

row = tblPeople.NewRow();

row["Name"] = "정우성";

row["Age"] = 41;

row["Male"] = true;

tblPeople.Rows.Add(row);

row = tblPeople.NewRow();

row["Name"] = "송혜교";

row["Age"] = 33;

row["Male"] = false;

tblPeople.Rows.Add(row);

tblPeople.AcceptChanges();

return tblPeople;

}

}

}

어댑터를 통해 SQL 서버로부터 읽은 데이터와 코드에서 직접 생성한 데이터를 병합해 보았다. MakePeopleTable 메서드는 다른 행을 추가하는데 이 메서드가 생성하는 테이블을 다른 사용자가 편집한 데이터라고 가정하자. 정우성과 송혜교를 추가하되 정우성은 나이가 기존 데이터와 다르고 송혜교는 새로 추가되었다. Merge 메서드로 이 테이블을 데이터 집합에 병합한 후 그리드로 출력했다.

아주 잘 병합된다. Merge 메서드는 원본과 새 테이블의 키를 비교하여 병합한다. 키가 같을 경우 새 데이터로 덮어 쓰는데 정우성은 원본에 36세라고 되어 있지만 새 테이블에는 41세라고 되어 있으므로 병합에 의해 41세로 수정된다. 기본키가 다르면, 즉 원본 테이블에 없는 행이면 새로 추가된다. 송혜교는 원본에 없었으므로 테이블 끝에 추가된다. 원본에 있던 고소영, 김태희, 배용준은 변함없이 유지된다.

Merge 메서드의 두 번째 인수 preserve는 원본의 값과 새 테이블의 값이 다를 때 원본의 값을 유지할 것인가를 지정한다. 생략시 디폴트인 false가 적용되므로 병합되는 테이블의 새 값으로 덮어 써진다. 병합되는 값을 더 최근값으로 인정하는 것이다. 이 인수를 true로 변경하면 원본 테이블에 있는 정우성의 원래 나이가 유지되고 병합되는 테이블의 값이 무시된다. Merge 메서드를 다음과 같이 호출해 보자.

DbADOTest.Merge(tblPeople2, true, MissingSchemaAction.Add);

정우성의 나이가 원본값인 36세를 그대로 유지한다. preserve 인수는 병합하는 쪽의 값을 취할 것인지 병합되는 쪽의 값을 취할 것인지를 지정함으로써 충돌되는 값 중 하나를 선택할 기회를 부여한다.

아무 테이블끼리 병합이 가능하지는 않으며 스키마가 같거나 아니면 적어도 자동 변환이 가능할 정도로 유사해야 한다. 위 예제와 같이 두 테이블의 스키마가 완전히 같으면 이상 없이 잘 병합되지만 열의 타입이 다르면 병합되지 않는다. 새 테이블의 Age 필드를 문자열 타입으로 바꾼 후 실행하면 예외가 발생한다. 문자열과 정수는 호환되지 않으므로 병합되는 쪽의 문자열을 정수로 바꿔 넣을 수 없다.

통상 같은 데이터 소스에서 읽은 다른 사본인 경우가 가장 많은데 이런 경우는 스키마가 완전히 일치하므로 병합에 문제가 없다. 다행히 약간의 유연성이 있어서 새 테이블에 원본에 없는 열이 추가되어 있을 경우에도 어느 정도 병합은 가능하다. Merge 메서드의 세 번째 인수는 스키마가 다를 경우 어떻게 처리할 것인가를 지정한다.

값	설명
Add	새 테이블의 스키마 정보를 추가한다. 이 값이 디폴트이다.
AddWithKey	새 테이블의 스키마와 기본 키 정보를 추가한다.
Error	예외를 발생시킨다.
Ignore	새 스키마 정보를 무시한다.

새 열을 원본에 추가할 수도 있고 무시할 수도 있다. 스키마가 달라서는 안된다면 아예 예외를 일으키도록 하여 병합을 거부할 수도 있다. MakePeopleTable 메서드를 수정하여 제일 뒤에 전화번호 컬럼을 추가해 보자.

private DataTable MakePeopleTable() {

....

col = new DataColumn("Tel", typeof(string));

col.AllowDBNull = true;

tblPeople.Columns.Add(col);

// 행 삽입

row = tblPeople.NewRow();

row["Name"] = "정우성";

row["Age"] = 41;

row["Male"] = true;

row["tel"] = "111-2222";

tblPeople.Rows.Add(row);

row = tblPeople.NewRow();

row["Name"] = "송혜교";

row["Age"] = 33;

row["Male"] = false;

row["tel"] = "333-4444";

tblPeople.Rows.Add(row);

tblPeople.AcceptChanges();

return tblPeople;

}

예제 DB에는 전화번호가 없어 두 테이블의 스키마가 달라졌다. Merge 메서드 호출문은 다음과 같이 수정해 보자.

DbADOTest.Merge(tblPeople2, false, MissingSchemaAction.Add);

preserve는 false로 바꾸었고 스키마 옵션은 Add로 지정했다. 새 테이블의 추가열이 원본 테이블에 추가되며 병합된 레코드는 이 열의 정보를 가진다.

Merge 메서드는 병합할 때 제약 조건을 점검하지 않지만 병합이 완료된 후 제약 조건을 일괄 점검한다. 그래서 원본 테이블의 기존 행도 추가된 열의 제약 조건을 위반해서는 안된다. 새로 추가된 Tel 필드의 AllowDBNull 프로퍼티가 true로 지정되어 있어 NULL값을 허용하는데 이 값을 false로 바꾸면 예외가 발생한다. 원본 테이블의 기존 레코드는 전화번호 정보가 없기 때문이다. Merge 메서드 호출을 다음과 같이 변경해 보자.

DbADOTest.Merge(tblPeople2, false, MissingSchemaAction.Ignore);

병합은 되지만 새로 추가된 열이 무시되고 나타나지 않는다. Error로 바꾸면 아예 예외 처리되어 병합이 거부된다. 이 경우는 스키마가 반드시 일치하는 테이블끼리만 병합할 수 있으며 제일 이상적이고 일반적이다. 애매하게 병합하느니 아예 에러로 처리해 버리는 것이 더 낫다.

Merge 메서드를 실무에 사용하려면 이보다 더 복잡한 상황을 고려해야 한다. 열의 목록은 같지만 일부 열의 타입이 약간 다른 경우도 있고 기본키가 다르게 설정된 경우도 있다. 이런 문제가 발생하면 예외도 발생하고 MergeFailed 이벤트도 발생하는데 코드에서 예외 상황을 적절하게 조정해야 한다.

또 편집중인 테이블끼리 병합시 각 열의 버전 관리 규칙과 행 상태의 변화도 복잡하다. preserve가 true이면 원본값을 덮어쓰지 않는다고 했는데 내부 규칙은 이보다 더 복잡하다. 원본의 Current 버전은 그대로 유지되지만 Original 버전의 값은 여전히 변경되며 행의 RowState는 Modified로 바뀐다.

행의 상태에 따라 어떤 버전이 어디로 대입된다는 상세한 규칙이 MSDN에 잘 설명되어 있지만 이 규칙을 숙지하여 미리 결과를 예측하는 것은 어렵다. 이런 복잡한 규칙은 애써 외울려고 하는 것보다 실무 상황에서 일단 병합해 보고 원하는 결과가 맞는지 확인해 보는 것이 좋다. 병합 규칙이 아무리 복잡하더라도 상식을 벗어나지 않는 수준이므로 기대한 대로 동작할 확률이 높다.

34-2-3.유효성 점검

유효성 점검이란 새로 입력된 값이 과연 제대로 된 값인지 검사함으로써 데이터의 완전성을 높이는 기술이다. 백엔드의 서버도 제약이나 트리거 등 무결성을 유지하기 위한 여러 가지 장치를 제공한다. 그러나 서버의 장치는 다분히 형식적이어서 중복 여부나 값의 범위 등을 기계적으로 점검할 수는 있지만 응용 프로그램 고유의 유효성까지 검사하지는 못한다. 예를 들어 개수나 점수가 허가된 범위의 값인지 파악할 수 있지만 주민등록번호나 상품 코드가 제대로 된 것인지까지는 점검할 수 없다.

서버가 지원하지 못하는 유효성 점검은 클라이언트가 직접 해야 한다. 서버에게 모든 것을 떠넘기지 않음으로써 서버의 부담을 덜어줄 수 있고 잘못된 데이터는 아예 서버로 전송하지 않으므로써 네트웍 트래픽을 줄여 전반적인 성능 향상에 도움이 된다. 유효성 점검은 서버와 클라이언트가 협조적으로 나누어 하는 것이 이상적이다. 테이블의 데이터가 편집될 때마다 다음 4개의 이벤트가 발생하는데 이 이벤트에서 입력된 값을 점검한다.

l ColumnChanging, ColumnChanged : 컬럼의 값이 편집될 때마다 발생한다. ing 이벤트는 편집중에 발생하며 ed 이벤트는 편집이 완료된 후에 발생한다. 유효성 점검은 값이 확정되기 전에 해야 하므로 주로 ing 이벤트에서 처리한다.

l RowChanging, RowChanged : 행이 편집될 때마다 발생한다. 레코드의 컬럼 중 하나가 편집될 때마다 발생하지만 어떤 열이 편집되고 있다는 정보는 전달되지 않는다. 편집중에 발생하는 ing 메시지와 편집 완료 후에 발생하는 ed 메시지가 있다.

열의 값이 바뀔 때마다 유효성을 점검하려면 ColumnChanging 이벤트가 적합하며 행의 모든 열이 다 편집된 후에 한꺼번에 유효성을 점검한다거나 다른 열과의 관계까지 고려해야 하는 경우는 RowChanging 이벤트가 적합하다. ed 이벤트는 편집된 후의 후속 조치가 필요할 때 처리하는데 사실상 별로 쓸 일이 없다. 이외에 행을 삭제할 때 발생하는 RowDeleting, RowDeleted 이벤트도 있다.

Validation

using System; ~ using System.Windows.Forms;

using System.Data.SqlClient;

namespace Validation {

public partial class Form1 : Form {

private SqlConnection Con;

private SqlDataAdapter Adpt;

DataTable tblPeople;

public Form1() {

InitializeComponent();

}

private void Form1_Load(object sender, EventArgs e) {

Con = new SqlConnection();

Con.ConnectionString = "Server=(local);database=ADOTest;" +

"Integrated Security=true";

Adpt = new SqlDataAdapter("SELECT * FROM tblPeople", Con);

tblPeople = new DataTable("tblPeople");

tblPeople.ColumnChanging +=

new DataColumnChangeEventHandler(tblPeople_ColumnChanging);

tblPeople.RowChanging +=

new DataRowChangeEventHandler(tblPeople_RowChanging);

Adpt.Fill(tblPeople);

dataGridView1.DataSource = tblPeople;

}

void tblPeople_ColumnChanging(object sender, DataColumnChangeEventArgs e) {

if (e.Column.ColumnName == "Age") {

if ((int)e.ProposedValue < 0 || (int)e.ProposedValue > 100) {

e.Row.SetColumnError("Age", "나이는 0 ~ 100 사이여야 합니다.");

} else {

e.Row.SetColumnError("Age", "");

}

}

}

void tblPeople_RowChanging(object sender, DataRowChangeEventArgs e) {

if ((bool)e.Row["Male"] == false) {

if ((int)e.Row["Age"] > 40) {

e.Row.SetColumnError("Age", "여성의 나이는 40세 이하여야 합니다.");

} else {

e.Row.SetColumnError("Age", "");

}

}

}

}

}

Form1_Load 이벤트에서 tblPeople 테이블을 읽어 그리드로 출력했다. 그리고 두 개의 ing 이벤트에 대한 핸들러를 등록하였다. 이벤트를 처리하지 않거나 핸들러에서 별다른 조치를 취하지 않으면 사용자가 어떤 값을 입력하든지 만사 OK이므로 잘못된 값이 입력될 수도 있다. 예를 들어 나이에 -10을 입력하거나 200같은 터무니없는 값을 입력하는 것도 가능해 이대로 두면 데이터가 엉망이 될 수도 있다.

잘못된 데이터나 논리적으로 의미 없는 값을 방지하려면 이벤트 핸들러에서 입력값을 감시해야 한다. 단일 열의 값을 감시하기 위해서는 ColumnChanging 이벤트가 적합하다. DataColumnChangeEventArgs 인수가 전달되는데 이 객체의 다음 프로퍼티를 통해 어떤 레코드의 어떤 열에 무슨 값이 대입되었는지 알 수 있다.

프로퍼티	타입	설명
Row	DataRow ⓡ	열이 있는 행 객체
Column	DataColumn ⓡ	편집되는 열
ProposedValue	object	제안된 값. 즉 열에 대입된 값이다.

핸들러는 이 정보를 보고 제안된 값, 즉 사용자가 입력하고자 하는 값을 받아들이거나 아니면 에러 메시지를 출력하여 잘못된 값임을 알린다. 에러를 출력할 때 메시지 박스를 열 수 있지만 사소한 실수에 대해 대화상자가 불쑥 불쑥 열리는 것은 바람직하지 않으므로 SetColumnError 메서드로 에러가 있음을 표시만 해 두는 것이 좋다.

행이 변경될 때인 RowChanging 이벤트에서는 행 전체에 대한 유효성 점검 코드를 작성한다. 단일값을 점검하는 것이 아니라 열간의 관계를 점검할 때 적합하다. 테스트를 위해 여자 고객은 40세를 넘어서는 안된다는 조건을 설정해 보자. 이 조건을 점검하려면 성별과 나이를 동시에 참조해야 하므로 열이 바뀔 때 점검하는 것은 부적당하며 행 전체를 점검해야 한다. RowChanging 이벤트의 인수로는 다음 두 가지가 전달된다.

프로퍼티	타입	설명
Row	DataRow ⓡ	변경되고 있는 행
Action	DataRowAction ⓡ	어떤 편집 작업이 수행되고 있는지를 알린다. Add, Change, Delete 등의 열거값 중 하나이다.

편집되고 있는 행에 대한 참조만 절달될 뿐 열에 대한 참조는 전달되지 않으므로 행 전체의 모든 값을 점검해 봐야 한다. Row의 Age와 Male 필드를 읽어 여자이고 나이가 40이상이면 나이열에 에러 표시를 했다. 실행해 보면 조건에 맞지 않는 레코드에 빨간색 느낌표가 나타난다.

문제가 있는 열에 에러 메시지를 등록해 놓을 수 있는데 이 메시지는 차후 GetColumnsInError 메서드로 조사한다. 에러 발생시마다 매번 귀찮게 하지 말고 상태란 등에 공손하게 실수를 지적하는 것이 바람직하다. 원한다면 에러 메시지를 등록하는 대신 즉시 메시지 박스로 오류를 알리고 아예 입력을 거부하는 것도 물론 가능하다. 단, 이렇게 하면 입력중에 메시지 박스가 열려 불편해질 수도 있으므로 아주 치명적인 값에 대해서만 메시지 박스를 열어야 한다.

void tblPeople_ColumnChanging(object sender, DataColumnChangeEventArgs e) {

if (e.Column.ColumnName == "Age") {

if ((int)e.ProposedValue < 0 || (int)e.ProposedValue > 100) {

MessageBox.Show("나이는 0 ~ 100 사이여야 합니다.");

e.ProposedValue = e.Row["Age", DataRowVersion.Original];

}

}

}

열에 대입될 값인 ProposedValue를 원래값으로 바꿔 버리면 입력이 거부된다. 이 처리는 열이 변경될 때만 할 수 있으며 행이 변경될 때는 할 수 없다. 왜냐하면 행이 바뀔 때는 편집되는 열에 대한 정보가 전달되지 않아 나이가 편집되어 조건이 위반된 것인지 성별이 바뀌어 조건이 위반된 것인지 알 수 없기 때문이다. 이 처리를 정 하고 싶다면 관련된 열 변경 이벤트에서 일일이 처리하는 수밖에 없다. Age 변경시 여성은 40세 미만인지 보고 성별 변경시 여성인 경우만 나이를 점검하면 된다.

안전한 데이터 관리를 위해 유효성 점검은 꼭 필요하다. 특히 사용자로부터 값을 입력받을 때는 무슨 짓을 할 지 예측할 수 없다. 사용자는 서비스 대상이지만 도무지 신뢰할 수 없는 존재이다. 데이터가 입력될 때마다 매번 유효성 점검을 하면 불가피하게 성능의 저하가 있을 수밖에 없다. 코드에서 값을 수정한다거나 신뢰할 수 있는 값이라는 것이 확실하다면 DataRow의 BeginEdit를 호출하여 유효성 점검을 잠시 중단할 수 있다. 이 메서드를 호출하면 EndEdit나 CancelEdit를 호출할 때까지 유효성 점검 이벤트가 중지된다.

34-2-4.바인딩

바인딩(Binding)이란 데이터 소스를 폼의 컨트롤과 연결하여 폼에 DB의 내용을 출력하는 기법이다. 지금까지 테이블을 DataGridView 컨트롤에 바인딩하여 내용을 확인하고 편집도 해 보았는데 그리드는 테이블 전체 내용을 통째로 보여주고 편집 기능도 막강해서 사용하기 굉장히 편리하다. 그리드뿐만 아니라 사용자에게 정보를 보여주고 입력받는 대부분의 컨트롤을 DB와 바인딩할 수 있다.

바인딩은 DB의 내용을 읽어 컨트롤에 출력하고 또 편집된 값을 DB로 다시 전송하는 복잡한 동작이지만 객체지향의 혜택으로 인해 몇 가지 프로퍼티만 조정하면 쉽게 구현할 수 있다. 하지만 관여하는 클래스가 워낙 많고 프로퍼티끼리 복잡하게 얽혀 있어 구조를 한눈에 파악하기는 난해하다. 다음장부터 마법사를 사용하면 바인딩은 자동으로 구성되므로 너무 상세하게 알려고 할 필요는 없고 대충의 동작 방식만 구경해 보자.

다음 예제는 SQL 서버의 tblPeople을 읽어들인다. 지금까지 배운바대로 연결 객체를 생성하고 연결 문자열을 대입한 후 어댑터로 tblPeople의 모든 레코드를 읽어 DbADOTest 데이터 집합의 tblPeople 테이블에 채웠다.

BindingTest

using System; ~ using System.Windows.Forms;

using System.Data.SqlClient;

namespace BindingTest {

public partial class Form1 : Form {

private SqlConnection Con;

private SqlDataAdapter Adpt;

private DataSet DbADOTest;

public Form1() {

InitializeComponent();

}

private void Form1_Load(object sender, EventArgs e) {

Con = new SqlConnection();

Con.ConnectionString = "Server=(local);database=ADOTest;" +

"Integrated Security=true";

Adpt = new SqlDataAdapter("SELECT * FROM tblPeople", Con);

DbADOTest = new DataSet("ADOTest");

Adpt.Fill(DbADOTest, "tblPeople");

}

}

}

서버와 연결하고 테이블을 제대로 읽기도 했지만 이대로 실행하면 폼에 아무것도 나타나지 않는다. 데이터는 가지고 있지만 사용자에게 보여줄 컨트롤도 없고 데이터를 읽어 출력하는 코드도 없기 때문이다. 폼에 텍스트 박스를 하나 배치하고 다음 코드로 첫 번째 레코드의 Name 필드를 출력해 보자.

textBox1.Text = (string)DbADOTest.Tables["tblPeople"].Rows[0]["Name"];

실행하면 텍스트 박스에 "고소영"이 출력된다. 그러나 이 코드는 DB에서 텍스트 박스로 데이터를 일방향으로 전송한 것에 불과해 편집한다거나 다음 레코드로 이동하지는 못한다. 텍스트 박스는 "고소영"이 어디서 왔는지도 모르고 주는대로 받아 표시만 할 뿐이다.

데이터 소스의 특정 필드와 컨트롤을 연결하려면 바인딩해야 한다. 바인딩이란 컨트롤과 데이터 소스를 짝짓는 것이다. 짝을 지워 놓으면 별다른 출력문을 작성하지 않아도 DB의 내용이 컨트롤에 자동으로 나타나며 컨트롤을 편집하면 DB의 내용도 같이 바뀐다. 뿐만 아니라 DB의 현재 위치가 바뀌면 컨트롤의 내용도 즉시 변경된다.

모든 컨트롤은 DataBindings 프로퍼티를 가지며 Binding 객체의 컬렉션인 ControlBindingsCollection 타입으로 정의되어 있다. Binding 객체는 컨트롤의 프로퍼티와 데이터 소스의 특정 필드에 대한 연결 정보를 가진다. 컨트롤과 DB는 통상 1:1로 연결되지만 1:다로 연결될 수도 있어 컬렉션으로 관리한다. 컨트롤의 프로퍼티마다 다른 필드와 연결할 수 있는데 예를 들어 텍스트 박스의 Text 프로퍼티는 Name 필드와 연결하고 BackColor 프로퍼티는 Color 필드와 연결할 수 있다.

컨트롤에 바인딩을 추가하려면 바인딩 컬렉션의 Add 메서드를 호출하거나 아니면 Binding 객체의 생성자를 호출한 후 Add 메서드로 Binding 객체를 전달한다. 다음은 컬렉션 클래스의 Add 메서드이다.

public Binding Add (string propertyName,Object dataSource,string dataMember)

바인딩할 컨트롤의 프로퍼티, 데이터 소스, 데이터 멤버를 차례대로 지정한다. Form1_Load의 끝에 다음 코드를 추가해 보자.

textBox1.DataBindings.Add("Text", DbADOTest, "tblPeople.Name");

텍스트 박스의 Text 프로퍼티를 DbADOTest 데이터 집합의 tblPeople 테이블의 Name 필드와 연결하라는 뜻이다. 이 코드에 의해 텍스트 박스에 필드의 값인 "고소영"이 출력된다. 뿐만 아니라 텍스트 박스를 편집하면 DB의 필드 값도 변경된다.

컨트롤을 필드와 바인딩하면 컨트롤뿐만 아니라 그 부모인 폼에도 바인딩 정보가 기록된다. 폼의 BindingContext 프로퍼티는 바인딩을 관리하는 BindingManagerBase의 컬렉션이다. 폼에는 여러 개의 컨트롤이 배치되고 컨트롤마다 다른 필드에 바인딩할 수 있으므로 바인딩 정보도 컬렉션이다.

BindingContext 안에는 BindingManagerBase로부터 파생되는 CurrencyManager나 PropertyManager가 저장된다. 데이터 소스가 여러 개의 값을 가지는 목록인 경우 CurrencyManager가 현재 위치를 관리하며 단일 값인 경우 PropertyManager가 바인딩을 관리한다. CurrencyManager의 Position 프로퍼티를 증감시키면 데이터 소스의 레코드 사이를 이동할 수 있다. 폼에 버튼 두 개를 배치한 후 다음 코드를 작성해 보자.

private void btnNext_Click(object sender, EventArgs e) {

BindingContext[DbADOTest, "tblPeople"].Position++;

}

private void btnPrev_Click(object sender, EventArgs e) {

BindingContext[DbADOTest, "tblPeople"].Position--;

}

BindingContext 프로퍼티의 인덱서로 tblPeople의 바인딩을 관리하는 CurrencyManager객체를 찾아 이 객체의 Position 프로퍼티를 증감시켰다. 버튼을 누르면 이전, 이후 레코드로 이동하면서 텍스트 박스에 출력되는 필드도 즉시 바뀐다.

뿐만 아니라 텍스트 박스를 편집하면 데이터 집합의 필드도 바뀐다. 김태희를 전지현으로 바꾼 후 다음으로 갔다가 이전으로 돌아와 보면 바뀌어 있다. 바인딩에 의해 컨트롤과 데이터 소스의 필드가 양방향으로 연결된 것이다. 이렇게 편집된 값을 어댑터의 Update 메서드로 전송하면 원본의 필드도 바뀐다.

새로 추가된 BindingSource와 BindingNavigator 컨트롤은 바인딩을 위한 간접 계층을 제공하여 바인딩 작업을 간단하게 처리하며 레코드 사이를 이동하거나 편집하는 사용자 UI도 제공한다. 이 컨트롤은 마법사가 관리하며 주로 타입드 데이터 집합과 함께 사용하도록 설계되어 있어 코드로 테스트하기는 어렵다. 다음 장부터 마법사와 함께 이 컨트롤을 사용해 볼 것이다.

34-2-5.맵핑

코드에서나 데이터베이스에서나 좋은 이름을 붙이는 것은 중요하면서도 어려운 일이다. 같은 범위내에서 중복되지 말아야 하며 기억하기 쉽고 입력하기 편한 적당한 길이의 이름을 찾기 쉽지 않다. 코드에서는 그나마 지역변수나 네임스페이스 등 이름의 중복을 피할 수 있는 장치가 있지만 데이터베이스의 테이블이나 컬럼에는 이런 장치가 없다. 그렇다 보니 개발중에 급하게 이름을 붙여 의미를 파악하기 힘들거나 너무 길게 작성해 쓰기 불편한 경우가 종종 있다.

설사 성의껏 이름을 잘 붙여 놓았다 하더라도 언어의 차이로 인해 곤란을 겪는 경우도 있다. 예를 들어 일본의 자회사에서 테이블을 디자인했는데 개념없는 일본 개발자가 컬럼명을 일본어로 작성했다고 해 보자. 닷넷은 유니코드 기반이어서 일본어도 문제없이 입출력할 수 있지만 문제는 우리가 쓰는 키보드가 일본어 입력에 적합하지 않다는 점이다. 이는 한글도 마찬가지인데 필드명을 한글로 붙여 놓으면 외국 개발자는 거의 환장해 버릴 것이다. 그래서 코딩할 때는 가급적 짧은 영문 명칭을 권장한다.

명칭이 문제가 되는 경우는 흔하다. 지나치게 축약형으로 작성하거나 대소문자 구성이 복잡해 입력하기 번거로운 경우도 있고 최종 사용자에게 암호문같은 명칭도 있다. 여러 가지 이유로 명칭을 바꾸어야 하는 경우가 왕왕 있는데 어댑터의 맵핑 기능을 사용하면 이름을 변경할 수 있다. 한글명을 영문으로 바꾸면 개발자가 편해지고 영문명을 한글로 바꾸면 최종 사용자가 보기 쉽다.

어댑터의 TableMappings 프로퍼티는 데이터 원본의 이름과 별칭의 짝을 관리한다. 디폴트로 이 프로퍼티는 텅 비어 있어 원본의 이름을 사용하지만 별칭을 주면 이후부터 지정된 별칭을 사용한다. 별도의 예제를 만들 필요 없이 DataAdapterTest 예제에 다음 코드를 추가해 보자. Fill 메서드를 호출하기 전에 맵핑 컬렉션을 생성한다.

using System.Data.Common;

private void btnOpen_Click(object sender, EventArgs e) {

....

DataTableMapping Mapper= Adpt.TableMappings.Add("Table", "tblPeople");

Mapper.ColumnMappings.Add("Name", "이름");

Mapper.ColumnMappings.Add("Age", "나이");

Mapper.ColumnMappings.Add("Male", "성별");

Adpt.Fill(tblPeople);

dataGridView1.DataSource = tblPeople;

}

TableMappings 프로퍼티는 DataTableMapping 객체의 컬렉션인데 이 클래스는 System.Data.Common 네임스페이스에 정의되어 있으므로 using 선언을 해야 한다. 한 어댑터로 여러 개의 테이블을 관리할 수 있으므로 테이블마다 하나씩의 DataTableMapping 객체가 필요하며 그래서 TableMappings는 컬렉션이다. 이 컬렉션의 Add 메서드로 새로운 DataTableMapping 객체를 생성한다.

public DataTableMapping Add (string sourceTable,string dataSetTable)

DataTableMapping의 ColumnMappings 프로퍼티는 DataColumnMapping 객체의 컬렉션이다. 한 테이블에 여러 개의 컬럼이 있으므로 이 역시 컬렉션이다. 이 컬렉션의 Add 메서드로 새로운 DataColumnMapping 객체를 생성한다.

public DataColumnMapping Add (string sourceColumn, string dataSetColumn)

인수로 원본의 컬럼명과 이후 사용할 컬럼명을 전달한다. 예제에서는 세 개의 컬럼 맵핑을 추가하여 영문으로 된 컬럼명에 한글로 된 별명을 붙였다. 맵핑을 다 만든 후 Fill로 채우면 맵핑을 참조하여 데이터 집합의 테이블, 컬럼명을 만든다. tblPeople의 열 이름이 한글로 변경되어 그리드 상단의 헤더에 출력된다.

필드명이 복잡하거나 비직관적이라면 친숙하고 쉬운 이름을 제공하는 것이 좋다. 아무래도 Name, Age 보다는 이름, 나이가 읽기 좋다. 더 간단하게 서버에 테이블을 요청할 때부터 별칭을 주는 방법이 있는데 SQL문을 작성할 때 AS 키워드로 별칭을 지정한다.

Adpt = new SqlDataAdapter("SELECT NAME AS 이름, AGE AS 나이, Male AS 성별 FROM tblPeople", Con);

내부적인 이름과 외부적인 이름이 달라야 하는 경우가 흔해 SQL도 서버 차원에서 열이나 테이블의 이름을 변경하는 기능을 제공한다. 서버에서 읽힐 때부터 아예 별칭으로 읽혀지는데 이 방법이 더 간단하다.