C#을 이용한 DB코딩 18

자. 이제는 기본적인 형태는 대략의 모습을 갖춘것 같다.

물론 앞서 팩토리와 함께 Strategy 패턴과, 기본적 Sington 정도를 같이 설명해주고 가야겠지만

다들 별 관심이 없는듯 하니 마무리를 향해서 나아가는게 더 좋을듯 싶다.

기본적으로 VS … 아니면 MS에서는 아주 쉽게 DB코딩을 하도록 여건을 만들어 주었음에도 우리는 그것들을 사용하지 않는다.

물론 알면서 사용안하는경우가 대부분이지만 실제적으로 소규모 프로젝트에서는 이런 제공된것들을 사용해 주게된다면 하나의 DB프로그램을 만드는데 걸리는 시간은 생각외로 짧은 시간내에 완성을 할수도 있다.

내가 처음 DataTable에 대해서 뒤적 뒤적 MSDN을 살펴보다가 놀란것은 GetChanges 매서드였다.

MSDN의 어느페이지 인지도 모르겠다만 이녀석이 덩그러이 나오던데 오~~ 이런게 다 있나 싶은 생각이 들었던것이다. 예전에는 아무생각없이 Dataset개체에 대해서 생각을 했던것들이 바뀌게 된 시발점이 이 함수였다. 일반적인 다중컬랙션 정도로 생각했던 개념이 깨어진 시발점이다.

결국 dataset을 알면알수록 저 매서드는 빙산의 일각이고, 생각외로 덩치가 큰 온갖 만능(?)의 클래스라는 생각이 드는걸 어떻게 설명을 할 수 있을까?...물론 저것 혼자가 아니라 저녀석을 기본으로 대부분의 컨포넌트가 잘 어우러지게 만들어 놓았기 때문이겠지만..

//----------------

Insert/update 나 delete를 한다고 생각할때 기본적인것은

입력할 필드값이 있어야 한다. <---



입력할것에 대한 데이터가 테이블의 컬럼을 늘리는것으로 감당할수 없는 경우가 있다.

또는 추가의 가능성이 높거나. 여타 몇가지 이유로 인하여

그럴경우에는 위와 같은 코드형태의 맵핑을 사용하게 되는데

-------------------------------------------------------------------

컴퓨터ID 부품Code 값

-------------------------------------------------------------------

Aaaaaa VGA100 ATI 비디오

Aaaaaa Hard100 100G 시게이트 하드

Aaaaaa RAm100 삼성2G 원칩

등등으로 맵핑을 시켜가는것이다.

잠시 화면단으로 예를 들면..



이런방식인데 업무상의 추가로 계속 늘어난다면..???





이렇게 설계했던것을



이렇게 바꾸어야 된다는 이야기다..

즉.. 컬럼을 늘려야 되니 여러가지 같이 변경해줘야 되는일이 발생하며 이것은 프로그램의 신뢰도 문제로 이어지게 된다.(사실상의 핵심은 귀찮다.)(궁금하거든 테이블의 컬럼을 늘려보아라.)

그렇다고 위의 이야기 처럼 단순 코드매핑을 꼭 해란게 아니다. 업무에 따라서..

그때그때 달라요~~~

테이블의 설계는 업무에 따른것이므로 지금 여기 적는 C# 강좌에서 관여할 일이 아니다. 만약.. 다른강좌(?)를 적게 된다면.. 그곳에서 따로 이야기 해주겠지만..

여하튼 지금은 이 두가지 경우에 대해서 모두 다 잘 처리되도록 해야된다는 이야기다.





이 두가지 형태의 테이블의 방식이 둘 다 처리해야 된다는것이다.

이런것은 사실상 문제가 아닌 SP에서 처리될것이므로 문제가 없긴 하다.(만약 한다면..)

그러나 최소한 지금 적는 코딩에서는 고려해가면서 이야기를 해줘야 되지 않겠는가.

자 두개의 핵심은 무엇일까? 둘다.. 결국은 하나의 값만 화면에 뿌려준다는것이 공통점이다.

다시금 설명하자면 위의 테이블이 두가지 방식이 있더라도 우리의 화면은 동일한 형태로 보인다는것이다.

그럼 뭐가 문제인가.. 첫번째의 경우테이블의 code값을 우리의 컨포넌트에 바로 1:1 셋팅을 하면 되는데 두번째의 경우는 테이블의 컬럼값을 셋팅해야 한다는 것이다.

쉽게 말해서.. 위에 적은말은.. 몰라도 된다.

뭐… 글을 너무 쉽게 적으려다 오히려 어렵게 적은듯 싶다.

앞서 컨포넌트와 데이타셋의 값을 매칭시키는 방식처럼 반대로

재귀호출된 값의 Foreach또는 리플랙션의 루프를 돌면서 설정된 값을 가져와야 된다.

그리고 그 설정된 값이 컨트롤의 특정값(여기서는 Tag)값과 설정된 값을 가져와서 하나의 컬랙션을 만들어 주면 되는것이다.

두번째로는 그 컬랙션을 받아서 DB에 인서트 하는게 기본적인형태일것이다.

(예제는 엑셀을 DB로 사용해서 계속 진행하겠다. 여로모로 시각적으로 보여주기 편하기 때문이다.)

테이블을 하나 만들고





테이블을 만든다.

자.. 여기서 문제가 있을것이다. computID의 경우는 고정값이 될것이고

-------------------------------------------------------------------

컴퓨터ID 부품Code 값

-------------------------------------------------------------------

Aaaaaa VGA100 ATI 비디오

Aaaaaa Hard100 100G 시게이트 하드

Aaaaaa RAm100 삼성2G 원칩

부품코드와 값만 계속 변경되는 형태로 쌓이는 것이다.

문제는 이것만이 아니다.



예를 들어서 고정값을 하나 더 늘리게 된다면 InputTime은 동일하게 처리가 될것이다.

또는



형태로 고정값이 계솔 늘어나는것을 감수해야 된다는 이야기다.

하지만.. 일반적으로 code 와 value의 경우는 고정적으로 두개라고 확정되는경우이고

즉 어쩔수 없이 우리는 다중열의 값을 가지는 형태로 사용해야 되는데 여기서 가장만만한게 DataTable이 되겠다.

------------------------------------------------------------------------------------

두번째 방식을 살펴 보자.





두번째의 경우는.. 값이 들어가는것 자체가 한줄로 모든값이 들어갈것이다.

컬럼명과 값 이런식으로 2개씩만 짝지워 지니 Dictioary를 사용하면 좋을것 같다.

여기서 우리는 효능이나 여러가지 스피드(?) 보다는 코더의 편리성을 생각해서 단순하게 코딩을 해야되지 않겠는가? 그렇다. 무시하고 이것도 dataTable로 처리를 하도록 하자.

그래야 최소한 입력루틴이 하나만 가지고 위의 두가지 방식을 다 처리할 수 있을것이다.

지금은 다루어지지 않았지만. 세번째로

DataTable의 GetChanges 매서드를 사용하게 될때 즉 그리드를 주고 거기서 변경된 값만을 DB에 처리해줄때도 사용하기 위해서는 모두다 집약시키는게 좋을듯 하다.

변화가 많고 변경이 있는것에 모두 적응하기 최적화라는 입장을 가지게 된다면 좋은라이브러리이나

이것은 또한 신뢰도적인 입장 안정적 코드의 입장에서는 반비례적인 현상을 가지게 한다.

글쓴이의 경우 최적화 또는 적합성적인것 보다는 코딩하는 사람의 단일한 인터페이스적인 형태를 더 선호한다. (이런 선호성은 Winform 코딩쪽에는 좋은선택으로 보여진다.)

Ps) SqlCommandBuilder 의 함수는 단일 테이블에 대한것만 생성

원본 위치 <http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1604&page=1>