삶이란 긴 이야기 - SungMin

설명들이 조금씩 짤려서 앞뒤가 잘 안맞는것은

이미 적은글을 여기 올리면서 짜르기 때문이다.

너무 사적인 이야기들은 역시 옳지 않은듯 싶기도 해서

DB시리즈는 20편까지로 마무리를 하고 뒷이야기들은 블러그에서 열심히 하는게 좋을듯 싶다는

생각을 한다.

Tstory인가 초청장 하나 신청해 보았지만 어케된지 오지도 않고 팔자려니 해서

그냥 바로 이글루스에 집을 차렸다.

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

자 앞서 설명을 했으니

이제 화면을 리플랙션을 통해서 datatable로 변경해 보자.

대략의 모습은 이렇게 넘어가게 될것이다.

뭐 하나 달라질것도 없이 앞서 셋팅한것과 별 다른 모습이 아니라고 생각된다.

앞서이야기 한것과 동일하게 foreach를 돌아서 알아서 만들어 주게 될것이다.

그럼 사용법을 대략 살펴 보도록 하자.

이런폼이 있다면.. 아니다.. 일단은.. 폼의 입력값의 증가도 보여줘야 할테니…

폼을 이렇게 만들었다고 치자. 즉 입력값을 3개라고 생각하자.

위의 콤보박스 그리고 아래의 2가지 필드

여기서.. 컴퓨터 ID는 고정값이라고 예상을 해보자. (이것은 앞 강좌에서 테이블 설계쪽을 유심히 보도록 하여라)

자 이렇게 입력을 했다고 보자.

이런식으로 고정값의 경우에 같은 형태로 입력이 되고 Code값과 Value값을 가져온다.

그럼.. 필드의 증가와 값의 증가를 동시에 테스트 해보자.

예를 위해서 이번에는 모니터의 값도 고정시키도록 하자.

실제 호출코드는 변경이 없이 전과 동일하다.

하지만.. 우리가 폼을 변경했다면..

이런식으로 입력할것들이 늘었다고 생각하자.

즉.. 고정필드는 고정필드에 따라 증가시켜줄것이고 코드와 값은 줄의 값으로 만들어 줄것이다.

다시금 말해서

뷰의 상황의 코드는 언제나 변경이 가능하다는것이다.

뷰의 경우는 필드가 더 생기거나 배치를 변경할수도 있을것이며 늘어날수도 있을것이다.

하지만 그것과 무관하게 우리는 알아서 DataTable을 통한 현재 뷰의 입력값을 받아올수 있을것이다.

자 이정도 했으며 아마도 앞서 이야기한 이것과 다른형태의 경우 필드와 바로 매칭되는 형태는 쉽게 코딩을 할 수 있을것이다.

이런식으로 입력했다면..

이렇게 구현이 될것이다.(한 6줄 되더라)

실제적으로 구현해봐야 되는 이유는 현재에는 보이지 않겠지만 실무에서 사용하려고 하면 반드시 매칭되지 않아야 되는녀석들도 있다. (물론 지금의 형태에서 쉽게 Tag값을 안 넣어주면 된다. )

또한 위의 code / value라고 적은것들을 고정값이 아닌 외부에서 받아서 처리한다던지 전체 코드를 변경하지 않고도 유연하게 만들기 위해서는 왜 이렇게 했는지 잘 살펴보길 바란다.(안보면 그만이지 뭐)

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

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

물론 앞서 팩토리와 함께 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>

오늘의 이야기를 시작해 보자.

앞서 그린 낙서적 스타일 그림을 보도록 하자.

이런게 있다면..

여기서 우리는 M을 변경해보도록 하자…

어쩌라고?를 외칠건데… 여기서.. 저렇게 되기위해서 우리는 머리를 굴려야 하는것이다.

C에서 M을 호출하는 루틴을 보면..

이 둘중에 하나를 적을수 있을것이다.

위의 코드는 둘다 동일하다.

예를 들어서

USB PORT = new 메모리스틱();

메모리스틱 PORT = new 메모리스틱();

과 동일하다는 이야기다.

처음 OOP를 접하는 사람들은 이런걸 잘 이해하지 못하는 경향이 있다.

예를 다시금 들어보자.

에서 우리는 이걸 평소에 하도 많이 사용하니 개념을 가지지 않는데

만 존재한다고 생각해 보자.

저 문자열을 어딘가 다시 사용하기 위해서는 어떻게 해야할까?

저 문자열이 적혀 있는 어느 공간 또는 주소값을 우리가 인식할수 있는곳에 넣어야 하는것이다.

실제적으로 tem에는 주소값이 들어가게된다.

조금 다르게 설명을 해보자.

여기서

라고만 하면.. 아래의 테스트 클래스에 적어놓은 "test class"가 출력이 될것이다.

OOP를 처음 접할수록

왠지 이렇게 적지 않으면 큰일이 날것 같다고 생각하는게 첫번째 문제이다.

뒤에 test() 라고 괄호를 적는것은 당신이 호출할 생성자함수를 말하는것이다.

(매서드와 함수라는 용어를 같이 사용할것이다. 이 둘은 같은 의미이다.)

단지 우리가 이렇게 적는것은 test란 개체를 나중에 이용하기 위해서 주소값을 가지는것을 의미한다.

그럼..

이 문장에 대해서 다시금 이야기를 해보자.

인터페이스로 적은것 또한 주소값을 저장하니 크게 문제없이 동일한것이 된다는 이야기다.

USB PORT = new 메모리스틱();

메모리스틱 PORT = new 메모리스틱();

와 마찬가지로..

USB PORT = new 프린터();

도 당연하게 이해해주기 바란다.

우리가 95년도에 처음 windows가 P&P라는 (PLUG & PLAY)란 이야기가 나왔을때 그저 오~~ 라는 생각을 가졌는지 모르겠으나 실제적으로 이것이 가능하게 되는 개념이 지금의 개념이다.

이미 10년도 휠씬전에 나온개념이고 이 개념덕분에 OOP가 살아있는것이다. (허접한 은닉성같은건 잊어버려라..)

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

어찌되었든.. 모듈을 변경하기 위해서.. (그림을 봐라 ms-sql에서 오라클로 변경이 되었다.)

컨트롤에 적은 코드를...

하여간.. 한줄을 바꾸어야 한다는것이다.. (한줄.. ㅠ.ㅠ)

앞서 열심히 그림을 그려줬지만.. 이 C라고 적은녀석은 변경하기 싫다는것이다.

변경이란 다시 컴파일을 해야된다는 이야기 이고 게다가 저렇게 선언한 코드가 매 폼마다 있다고 가정한다면… 그것참 거시기 한것이다. 물론 그렇게 코딩할수도 있고 한곳에다만 적어서 코딩할수도 있을것이다.(역시 소형프로젝트에는 절대적 무용지물인 이야기들이다..)

그래서 이것을 분기분으로 작성하기도 하자.

말하자면 이정도 될것이다.

이것을 내부에 두는게 아니라… 외부의 클래스로 만들어 두고 그것을 함수로 불러다 사용하자는 것이 이 심플팩토리의 이야기다.

왜 이렇게 하냐면 앞서 만들었듯이 계속 Excel이라든지 Access라든지 선택사항이 늘어나기 때문에 이 선택사항에 대한 함수만 변경하기 위해서 변경부위를 밖으로 빼자는 이야기다.

이걸 가지고 일반적으로

함수형 팩토리 패턴

또는

Simple Factory 패턴이라고 한다.

뭐 말그대로 심풀하고.. 하나의 함수로 이루어질 수준이라서 굳이 설명할것들도 없다.

마지막으로 위의 이야기가 다 필요없는.. 기본적으로 ms에서 이것까지 지원하도록 만들어 두었다.

http://mkex.pe.kr/kims/bbs.php?table=Tbl_Lecture_CSharp&query=view&uid=68&p=1

이 링크의 강좌를 보도록 하여라..

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