삶이란 긴 이야기 - SungMin

보여주는것을 View라고 하는데

MVC 란 것부터 이야기를 해보자.

MVC를 누누이 이야기 하지만 난 올바르게 알지를 못한다.

하지만 이렇게 이야기를 해보자. 앞서 그림을 그려왔듯이 여러가지 상황에 적절하게 프로그램을 변경하기 위해서는 흔히들 말하는 "레고블럭"같은 코딩을 하길 원했다는것이다.

그 레고블럭이 되기 위해서는 첫번째가 인터페이스다.

여기서 인터페이스란 레고블럭처럼 튀어나온곳과 들어간 곳이 정확하게 맞아야 된다는 이야기다.

그렇치 않다면 조립이 불가능하다.

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

3가지 형태로 코딩을 나누게 되면 일단 각각의 개체를 다른형태라고 하더라도 즉 변경된 다른개체이더라도 교체가 가능하고 각각의 개체는 수정이 되지 않는 차원에서 수정이 필요한 부분만을 교정하면 된다는 이야기를 하는것이다.

MVC 란 패턴이 이야기 하는것은 (내가 해석하기에)

세가지 파트를 나누어란 의미에 불과하다.

하지만 이 부분한 이야기들로 인해서 M에서 V과 통신을 하는가 데이터 교류가 있는것에 대해서

이야기를 나누게 되거나 현재의 모양인 C를 통해서만 모든것이 이루어 져야 한다는 측면들 이야기들에 대해서 분분하다.

모든것을 떠나서 그런 이야기들은 그저 이야기 들이고 핵심적으로 3개의 파트가 독립성을 유지하고 정보를 이동하기 위한 교량(?) 다리적인 핵심정책이 있어야 된다는것이다.

내가 적은 이야기에서

중간의 Controll이란 녀석은 Model과 오로지 DataSet을 통해서만 정보를 이동시키고

View란 녀석과는 View개체 자체의 주소만으로 정보를 이동시키게 될것이다.(실제적으로 Control을 의미한다.)

강조하지만 여기에는 분명 C와 V가 이야기 하기위한 표준인 interface가 정의되어야 하며

C와 M이 교류하기 위한 interface도 정의되어야 할것이다.(이건 이미했다.)

(--시간이 되면 Model이란게 DB만을 이야기 하는것이 아니라 하나의 개념이란것을따로 설명하겠지만 지금은 넘어가자--)

이것은 표준이 아니라 단지 내가 정한방식일뿐이다.

단지 3개의 파트를 나눈것에 불과하다는것을 유심히 이해해주기 바라며

이것은 또다른 형태의 레이어와 유사하게 된다.

응표세전네데물이라고 장난스럽게 외우던 OSI 7개층이 현재까지 네트웍의 모든것을 좌우하고 있듯이

MVC 란 3가지 파트의 구분은 현재의 어플리케이션의 모든것의 중심축에 있다는것을 기준으로 코딩하는것이 좋을듯 싶다.

만약 이런한 이해가 바탕이 되면 GOF에서 이야기하는 패턴들이 이 3가지 층을 유지하기 위한 방법이란것을 이해하게 될것다.(GOF도 사전에 없으므로 묻지 마라)

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

자 앞으로 우리는 윈폼에서 View와 그리고 Asp.net에서 View 그리고 마지막으로WPF에 대한 뷰를 보게 될것이다.

(참 다 아는이야기를 이렇게 힘들께 썰을 푸는것 처럼 한심하게 느껴지는것도 없으리라..)

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

우리가 만들어 놓은 것은 일종의 DB의 접속이다.



예를 들어서 테스트 삼아 엑셀디비를 이용해서 우리가 어떤 어플리케이션을 만들었다고 생각하자. 그런데 이 규모가 점점 커지다 보니 ms-sql로 변경을 했다는 가정을 해보도록 하자.

실제적으로



디비의 연결은 위에 한줄 적게되니 크게 많이 적지는 않는다. 각 폼마다 몇번 바꾸어 주면 되는것이고 심지어 static같은 형태로 선언이 되어 버렸다면 더군다나 수정할만한 가치가 없는게 아닐까 싶은 수준이다.

하지만 만약 DB의 변경이 일어나면 어떻게 해야하는가?

결국 우리는 "컴파일"이란 작업을 다시 해야지만 하는것이다.

그것도 클래스를 일일이 다 바꾸어서 말이다.

그런데 사실 겨우 우리가 만드는 사소한 프로그램은 그런것들이 문제시 될것이 없다.

더군다나 DB를 변경할일도 없고,./

그렇다고 대형 프로젝트에서는 아키택쳐들이 다 알아서 할테고 말이다.

즉 지금 내가 글을 적을 이유가 없는것이다.

이걸 팩토리 패턴이란것으로 만들만한 이유가 없는것이다.

말그대로 그냥 구현하기도 싫으니 대충 손으로 몇번 끄적거리고 컴파일만 다시하면 그게 더욱 더 쉬울것 같다.

팩토리를 이야기 하려다 보면 설정파일도 한번쯤 끄적여야 겠고

게다가 팩토리 패턴도 결국 새로운 개체가 생성되면 컴파일을 다시해야 되는것들이고 그런것이 아닌것을 보여주려면.. 리플랙션같은(reflection 이건 또 뭐야?? 사전에는 있긴 하다만… 어쩌라고)이야기 까지 가야하니 참 한심나름이다.

이글의 주 대상(?)이 또한 이런걸 알길 원하지 않을것이고 말이다.

계속 글을 적었다 지웠다를 반복하다가. 이게 아니다 싶은 생각에 이런 결정을 내렸다.

글을 읽는건 읽는사람 맘이니 … 알게 뭐냐

적는건 내맘이니.. 알게 뭐냐..

그렇다.

역시 낙서란 개념은 맘편한것이다. 그러니 이제부터 진정 낙서의 세계로 가보자.

주구장창 앞뒤고 뭐고 일명 뜬금없는 이야기를 해보자.

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

자… 내맘대로의 이야기를 시작해 보자.

기본적으로 사용자란 넘이 있다.



이 사용자는 요구사항이 있을것이고



이걸 해결할 것은 DB와의 이야기 일것이다.



저 요구사항을 해결하기 위해서 어플리 케이션이 필요하게 되고 우리 코딩하는 사람들은 프로그램을 작성해야 할것이다.



그러다 사용자 2라는 녀석도 비슷한 유형의 프로그램이 필요하게 된것이다.

그래서 프로그래머들은.. 위의 프로그램을 다른 사용자에게 팔았다.



하지만 사용자 2는 요구사항이 달랐다. 결국 프로그램을 열심히 수정해 줘야지만 했고

예전로직과 함께 이상한 덩치큰 괴물이 되어버린것이다.



어찌되었든 돌아는 갈것이다. 만들어는 줬으니 이런일이 잦아 지니 여러가지 고민을 하게 되었다.

좀 더 유용한 방법은 없을까?



그래서 만든게 이런 형태의 3단계를 나누어서 하는게 어떨까 하는 생각을 가지게 되었다.

이렇게 나누어 두면 사용자 1의 경우 sql을 포기하고 oracle로 가더라도 변경이 가능하기 때문이다.



예를 들어서 이런게 가능하다는것이다. 여기서 전체를 변경하는것이 아닌 오라클과 관계된 부분의 코드만 바꾸게 되니 일단 전반적인 1/3만 코드를 수정하면서 전체를 구성하는 무리가 없어진것이다.

이게 비로 MVC가 아닐지라도?... 그냥 MVC 라고 적어보도록 하자.



즉 저기에 적은 M이란 녀석만 바꾸면 되는것이다.

우리가 만든



이 3개의 클래스는 각각의 M에 속할것이다.

MVC 가 사전에 안 나와 있어서 뭔 뜻인지는 나도 모르겠다.

여기서 우리가 주목할것은



이부분이다.

이녀석은 우리가 적은..



인터페이스가 아닐까 하는 생각을 해본다.

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



그럼 이녀석은 뭔가? 그렇다. 그것은 당신이 해야되는 숙제이다.

인터페이스를 만들던지 약속을 어떻게 하던지 그건 당신의 숙제이다.

자.. 우리는 여기서 저기에 있는 "M"이라고 적은 이상한것을 두어번 바꾸어 본듯하다.

그럼 이번에는 저기에 있는 V라는것을 두어번 바꾸어 보도록 하자.



참 그림 얄긋다…. (그려주는거에 감사해라..!!!)

Ps)

솔찍하게.. 다 그리고 보니 그림 참 아니다. 젠장할…

이렇게 살아야 하는거야 그런거야?

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

자. 분위기를 몰아서

이번에는 엑셀을 작성해 보도록 하자.



엑셀 또한 똑같은 인터페이스를 상속받아서 계속 작성해보자.



엑셀의 경우는 많이 사용하고 또한 질답에도 꽤 올라오니

강좌와 무관하게 번외(?) 편으로 조금 더 설명을 적어보겠다.

여기서 엑셀은 저장프로시저를 사용하지 않으니 실제적으로 callSP는 필요가 없다.

더군다나 저렇게 무용지물의 코드를 적을 필요도 없다.(다 내가 게을러서 그렇다. )

위의 코드의 택스트는

class setDBExcel : IDataBase

{

static OleDbConnection conn = null;

public setDBExcel(string ePath)

{

if (conn == null) conn = new OleDbConnection();

conn.ConnectionString = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + ePath + @";Extended Properties=""Excel 8.0;HDR=YES""";

conn.Open();

}

public DataSet callSQL(string SQL)

{

DataSet DS = new DataSet();

OleDbDataAdapter DA = new OleDbDataAdapter(SQL, conn);

DA.Fill(DS, "getDataSet");

return DS;

}

public DataSet callSP(string SPname, Dictionary<string, string> Para)

{

DataSet DS = new DataSet();

return DS;

}

}

이렇게 적어야 하고 유심히 볼것은 연결 스트링 정도 수준이다.

호출하는 코드는 이렇게 된다.



setDBExcel DB = new setDBExcel(@"c:\test.xls");

dataGridView1.DataSource = DB.callSQL("SELECT * FROM [sheet1$]").Tables[0] ;

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

화면은..



이런 엑셀 화면을 불러왔을때



이렇게 나오게 된다.

당연히 쿼리를 이용해서 제어가 가능하다.

엑셀에 대한 몇가지 링크를 남겨둔다.

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNo=8&no=1159&ref=1159

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNo=8&no=927&ref=927

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNo=8&no=926&ref=926

읽어볼만한 글중 하나

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNo=8&no=1474&ref=1474

인터넷을 돌아다니다가  정리가 잘 된 글을 발견함

http://blog.naver.com/nuwanamj/10016358421

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

자 이제 내가 하려고 했던 이야기중에 하나인 DB 클래스에 대해서 계속 살펴보도록 하자.

우리가 연결해야 하는것들은..

 

Excel

MDB

Oracle

Ms-sql

My-sql

 

등 아주 많은… 개체들이 있다.

그럼 어떻게 해야할까?

뭐 어쩌겠나 각각의 개체들을 모두다 만들어 줘야 한다는것이다.

하지만 내가 앞에서 적었듯이 내가 만든게 점점기억이 나지않게 된다는 사실이다.

결국 이런문제를 해결하기 위해서는 우리는 "표준"이란것을 재정할 만한 필요가 생긴것이다.

(앞에서 적은 USB를 생각해보라.)

우리가 만든 클래스를 상기해 보자.(내가 만든것이였나)



우리가 만든것의 표준을 callSP와 callSQL을 생각해 보자.

즉 우리는 ms-sql을 접속을 해도 callSQL이란걸 쓰고 오라클도 그리고 심지어 Excel파일도 저렇게 사용을 하고 싶은것이다.

앞에 코딩을 봐서 알겠지만 저렇게 만들어 주는것은 사실은 큰 문제가 아니다.

20줄 정도 되었나?

그럼 이번에는 그 ms-sql의 코딩을 가지고 인터페이스를 상속한채로 만들어 보자.

그리고 앞에서 적은 코드와 비교해 보자.



이게 앞서 작성한 코드이다.

20줄은 좀 넘는것 같긴하다. 이것을 인터페이스를 상속받아 사용하면 어떻게 되는가?

아쉽게도..



겨우 이것만 달라질 뿐이다.

단지 위에 인터페이스를 선언해주고 클래스에 상속자만 적어줄뿐이다.

뭐하자는 겜인가? 싶지 않나.. 그렇다 별게 없다.

그럼 우리는 왜 인터페이스를 사용하는가? 아까 말했듯이 그냥 표준이라는것이다.



왼쪽의 인터페이스를 오른쪽의 클래스가 상속했다고 위에 동그라미가 그려지는게 아마도 다인듯 싶다.

인터페이스를 만들지 않고도 우리가 만들 개체들이 모두 callSP와 callSQL이라는 함수만 만들면 되는것이 아닐까? 그러게 말이다.

하지만 그렇게 한다면 다른이가 또는 우리가 나중에 클래스를 사용할때 그렇게 한것인지 아닌지를 구분하기에는 시간이 걸릴것이다. 그러니 귀찮더라도



이렇게 상속한다고 적어주는게 좋을듯 싶다.

그럼 이번에는 오라클용 클래스를 하나 만들어 보도록 하자.



이렇게 두개의 클래스가 인터페이스를 상속받고



이렇게 구현이 될것이다. Ms-sql보다는 조근 더 긴것 같다.

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

자. 이제는 인터페이스에 대한 낙서를 적어보자.

미리 말해두지만 정말 낙서이다.

예전에 처음 인터페이스를 접하게 되었을때 난 이런생각을 했다. 내가 만드는 모든 클래스들은

만드는클래스 xx = new 만드는클래스();

Xx.open();

Xx.close();

같이 하면 무조건 그 클래스가 작동하는것을 말이다.

하여간.. Open 으로 시작해서 close로 끝나고자 했던 기억이 난다.

그시절에도 물론 지금도 크게 생성자에다 뭘 집어 넣는걸 좋아하지 않았던 이유로 왜 생성자를 좋아하지 않았는지는 나도 모르겠지만..

그냥 왠지 생성자에 넣는게 좀 그랬더랬다..

하여간 그건 그런거고.. 저런 인터페이스를 가지겠다는 생각을 종종하곤 했다.

문제는 세상이 그리 만만할 수준이 아니란것과 너무 많은 형태의 클래스들이 생겨나니 저런것이 힘들다는것들을 알게되고 두번째 생각한것은

인터페이스군을 만들자는 생각이였다. 네트웍에 따른 인터페이스 / DB에 따른것 / …..

이런식으로 표준 인터페이스를 만들어서 거기에 맞도록 다른것을 끼워 맞추는것이다.

왜냐면 난 내가 만들어 놓은 클래스 마저 사용법이 기억이 나지 않기 때문이다.

그럼 결국 아무런 클래스나 내가 만든것들은 무조건

Open해주면 되고 나중에 close 해주면 된다고 생각해 봐라..

즉 그렇게 한다고 정의했다면 만약 그 클래스가 특별히 인자를 요구하지 않는다면 사실상 클래스의 사용법을 알지 않아도 된다는 이야기가 된다.

두번째 문제는 필요없는 인자를 넘기기 위한 코딩을 괜히하게 되거나 할 수도 있겠지만..

하여간 이런생각들이 자꾸만 들게 됨으로 인해서 닷넷에서 제공하는 것마져 내 방식에 맞도록 하고자 하는 생각들이 들게 되고 그렇게 하는게 Adapter라는 패턴을 이야기 하는줄 나중에 알게 되었다.

하지만 문제는 말이다. 나같은 단순한 사람도 그런생각을 하듯이 닷넷을 만든이도 그런 생각을 했다는 것이다. 그럼에도 불구하고 그러지 못하는것은 너무 나도 필요한게 많기때문일지라.

하여간 그 인터페이스에 대한 이야기를 해보도록 해보자.

처음 닷넷이거나 또는 자바이거나 아님 c++이거나 객체지향이란 언어를 접해서 하나의 난관이라고 이야기 할수 있는게 이넘의 인터페이스다.

문제는 인터페이스가 어려워서가 아니라 이걸 설명하는 책이 더럽게 어렵다는 것이다.

아님 내가 머리가 나쁘거나.

하여간 지금도 이해를 못하니 어쩌겠니.. 그냥 그러려니 하고 살아야 될듯 싶다.

인터페이스란

한마디로 "표준" 이다.

앞에서 내가 이야기 한것 처럼 난 open으로 시작해서 close로 끝내고 싶다고 생각한것 처럼 이런 표준을 정한다는것이다.

그것이 전부라고 생각하면 된다. 이 표준이란것에 대해서 이야기를 해보자.

우리는 예전에 24pin의 핸드폰 충전기 이전에는 항상 그 핸드폰에 맞는 충전기를 가지고 있어야 했다. 그래서 다른회사의 핸드폰충전기로는 충전자체가 불가했다.

하지만 지금은 어떤가? 24pin으로 정통부가 표준을 정하니 모든 핸드폰이 같은라인에 충전이 가능하게 되지 않았는가?

그 24pin이란게 표준이다. 그게 인터페이스고

또 다른이야기를 해보자.

USB는 이제 기본적 인터페이스가 되어 버렸다. 이것을 통해서 우리는 프린터, 랜도 연결하고, 하드도 연결한다.

Usb가 하드는 아닐진데 말이다.

개체와 컴퓨터를 연결하는 인터페이스가 USB인것이다.

이런 인터페이스가 생성되면 어떤가? 왠지 어떤장비를 만나게 된다고 생각을 해보자.

예를 들어서 디카를 샀다고 보자. 그런데 이녀석이 USB연결포트가 있는것이다. 그럼 우리는 어떤가? 왠지 자신감이 생긴다. 이녀석의 자료는 일단은 컴퓨터에 연결하면 뭐가 될것같은것 말이다.

당신이 빔프로젝트를 샀는데 USB잭만 있다.

느낌이 좀 색다르지 않나.. 당신은 무슨장치인가보다 단지 연결할것이 USB라는 이유만으로도 일단 그 장비에 대해서 일말의 자신감(?)인지를 느낄수 있게되는것이다.

그리고 왠지 모르겠지만.. 당연히 연결잭에 꼽기만 하면 다 알아서 될것같은것들..

그런 기분이 바로 인터페이스이고.. 그렇게 하기 위해서 표준이란 걸 만드는것이다.

자… 이제 이분위기를 이어서 계속 이야기를 해보면

"I"라고 시작하는것들은 모두 인터페이스라고 하자고 정의했다. (그냥 묵시적이다. -_-;;)

Iysm 이란 인터페이스가 있다고 치자. (ysm은 나의 이니셜이다.)

이 인터페이스는 open으로 시작해서 close로 끝나는것이다.

처음 만나는 xyz라는 클래스가 있는데 이녀석이 Iysm이란 인터페이스를 가지고 있다고 생각해 보라. 단지 우리는 싱긋 미소를 짓고 이유없는 open과 close를 때리면 그녀석은 알아서 동작을 하게 될것이다. (close하다가 끼이면 정말 괴롭다. -_-;; 이런농담을 알아듣는 인간이 있을까?)

마치 usb를 이용해 컴퓨터에 디카를 연결하면 뭔가가 되는것 처럼..

인터페이스란 이런것들이다.

Ienumerable 같은것은 우리는 쉽게 접하는데 일단 이녀석이 구현되면 foreach가 가능하다는 생각이 들지 않는가?

인터페이스란 여하튼 구현되어 있다는 사실만으로 상당히 좋은것이다.

내가 가지고 있는 노트북은 "블루투스"가 안된다.

구현되어 있다면 난 핸드폰에 있는 "블루투스" 기능을 통해서 서로 연결하지 않아도 통신이 될텐데 말이다.

우리가 만드는 클래스는 위와같은 노트북, 핸드폰 처럼 하나의 객체이고

그 객체끼리의 표준을 구현해 둔다면 우리는 좀 더 유용한 클래스를 만들게 될것이다.

CF)

http://www.simpleisbest.net/archive/2008/06/23/2423.aspx

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

일단은 앞서 보았듯이 콤보박스는 셋팅이 가능하다

그럼 콤보의 사촌인 리스트 박스는 어떻게 될까?

listBox1.DataSource = DT;

listBox1.DisplayMember = DT.Columns["Expression"].ToString();

listBox1.ValueMember = DT.Columns["Value"].ToString();



당연히 이런방식으로 처리가 될것이다.

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

자 여기서 숙제 하나 !



이런 체크 리스트 박스를 가지고



이런식으로 테두리를 없게 하고 화면을 바탕을 같게하면.. 이런방식으로 처리가 된다.

즉 가끔 황당(?) 하다기 보다는 체크박스를 일일이 손으로 끌어다 배열하는 경우가 있던데 물론 그게 나쁘다는게 아니라.

양이 많게되면 감당이 안된다는 것이다.

또한 문제는 어쩌다 그 항목이라도 하나 늘게되면 얼마나 많은 수정을 해야하는가?

그런건 어떻게 하면 쉽게 할수 있을까?

이런방식은 프로그램의 옵션을 줘야 할때 매우 유용할수도 있다.

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

자 이제는 트리뷰를 한번 보자.

트리뷰의 경우는 일반적으로 인간의 머리로는 생각할수가 없다.

실수다.. 내 머리로는 힘들다. 아마도 당신의 머리로는 크게 문제가 없을듯 하다.

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNo=8&no=1224&ref=1224

이런글이 있는데.. 나쁘지 앟은듯 하다.

필요하신분은 참고를 하도록 하고..

문제는 이런경우에는.. 또 하나의 필드를 늘려야 하거나.. 한정적이게 마련이다.

하지만 인간이 보기에는 좋을듯 싶다.

문제는 자유롭게 배치하기 위해서는 어떻게 해야할까?

즉 어쩔수 없이 우리는 부모노드에 대한 값을 가지고 있는 형태로 DB를 설계해야 될것이다.

또 ER-win을.. ㅠ.ㅠ 안습이다.

트리뷰에 대한것은 우리에게 너무나도 친숙한 디렉토리의 개념을 이해하면 된다.

모두들 한번씩은 겪어야지만 하므로 대부분 전체 디렉토리의 파일을 구하는것들을 한번씩 작성해 보았다고 생각이 든다.

거의 절대라고 해야할정도로 재귀호출을 피할수 없으므로 트리뷰또한 이 재귀호출을 피할수 없다고 보면 된다 마치 이녀석은 당연히 그래야 한다는것처럼 말이다.

또는 아래에 내가 적은 폼내부의 그룹박스안에 포함된 컨트롤을 다시금 조사하기 위해서도 재귀호출을 사용했듯이 이녀석 또한 입력에도 재귀호출을 사용해야지만 한다는 이야기다.

또한 적어줄지 안적어줄지(?)는 모르지만 우리에게 친숙한 "메뉴"구조도.. 이와 유사한 방식으로 대부분 코딩을 한다.(아닌가 나만 그런거야 그랬던거야?)

뭐 이미 정석(?)적인 코딩이라서 뭐라고 할만한게 없다고 본다.

요약하자면. // 계층적 구조 = 재귀호출 알고리즘

이라는 공식이 있다.(내가 만들었던가?)

이미 널리(?) 알려져 있기도 하고 대부분 알고 있는 내용이라 대충 하고 가자.



이런식의 모양을 만들고

다시금 물리테이블을 만들자..

물론 실제적인 프로젝트에는 좀 더 많은 정보를 넣기도 한다. 게다가

몇가지 체크박스라든지 옵션을 주기위한것을 미리 정의해두기도 한다. 그런것들은 어차피 프로젝트에서 실제적인 공통모듈을 만드는 사람들의 이야기니 대충 생략하자.



대충 이렇게 또 만들기로 하자.

CREATE TABLE TreeView

(

Seq int identity NOT NULL ,

TreeViewID varchar(20) NULL ,

Expression varchar(100) NULL ,

Parent int NULL ,

Memo varchar(1000) NULL ,

ViewSeq char(18) NULL ,

UseBool char(1) NULL ,

image image NULL

)

Execution Successful

ALTER TABLE TreeView

ADD CONSTRAINT XPK트리뷰 PRIMARY KEY NONCLUSTERED (Seq ASC)

Execution Successful

Schema Generation Complete

2 query succeeded.

"XPK트리뷰 " 이라니.. ER-win은 확실히 버그가 좀 있다.

뭐 버그야 있던말던.. 예제야 무슨 상관이겠는가.

자 계속 되는 삽질을 해보도록 하자.

폼은.



이런식의 트리뷰와 오른쪽은 그냥 데이타뷰이다.

왜냐면.. 데이터가 어떻게 나오는지는 봐야되지 않겠는가 콤보박스처럼 말이다.

자 이제는 예제를 위한 데이터를 넣어야 할것이다.

Insert를 또 때려야 하나 ㅜ….ㅠ

젠장.. 예제 하나 하는데도 이렇게 손질이 많이 가다니

근데 정말 내가 왜 이걸 적고 있는지..

나중에 책이라도 하나 써야겠다. 문제는 바닥권의 실력이라 누가 사볼가 싶다만..

Insert를 때리려고 보니 위에 테이블이 다 null허용을 했네 흐흐.. 귀차니즘이다.

자 insert를 어케 적어볼까?

insert into treeview(expression,parent) values('아파트',-1)

insert into treeview(expression,parent) values('111동',0)

insert into treeview(expression,parent) values('222동',0)

insert into treeview(expression,parent) values('333동',0)

insert into treeview(expression,parent) values('444동',0)

insert into treeview(expression,parent) values('1호',2)

insert into treeview(expression,parent) values('1호',1)

insert into treeview(expression,parent) values('1호',5)

뭐가 뭔지는 모르겠고 대충 적자.



이렇게 그려지게 될것이다.

이 소스는

닷넷 프로그래밍 정복의 "김상형"씨의 소스를 적당히 수정한것임을 미리 밝힌다.



사용법은



이런식이 될것이다.

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

아무래도 이야기의 질이 다소 떨어지는듯 싶다. 너무 이야기가 중구난방으로 흐르는듯 해서 하나의 집약하는 방법을 다시금 생각해 봐야겠다.

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

자 이제 앞써 이야기 했던 ER-win은 친숙해 졌을거니 가볍게 테이블을 하나 추가해보자

1. 테이블을 하나 만들고(콤보박스용)

2. 그 테이블을 이용해서 데이터를 가져오도록 하는 DB접속 클래스를 하나 만들고

3. 그 db접속 클래스를 오라클과 ms-sql용으로 만들고..

4. 다시그 그 클래스를.. 요리보고 저리보고를 할것이다.

테이블은 이렇게 만들어 보자.



차수는 정규화적 규칙을 위한 PK를 만들고

콤보박스ID란 각 콤보박스의 고유번호라고 생각하자.(오타를 쩝.. 웃으며 넘기자 고치는게 귀찮다.)

하여간 심플한 테이블을 하나 만들고 바로 물리테이블을 다시 또 만들자.



대략 위와같이 만들수가 있겠다.

CREATE TABLE Combo

(

SEQ int identity NOT NULL ,

ViewSEQ INTEGER NOT NULL ,

Expression varchar(100) NOT NULL ,

Value varchar(100) NOT NULL ,

UseBool char(1) NULL ,

Memo varchar(1000) NULL ,

ComboID varchar(20) NOT NULL

)

Execution Successful

ALTER TABLE Combo

ADD CONSTRAINT XPKCombo PRIMARY KEY NONCLUSTERED (SEQ ASC)

Execution Successful

Schema Generation Complete

2 query succeeded.

대충 이렇게 생성을 하도록 하자.(너무 안일한 자세인가?)

1. 폼설계는 대충 하자.



이렇게 하고 버튼의 코드에는

setDB DB = new setDB();

dataGridView1.DataSource = DB.callSQL("select * from combo").Tables[0] ;

이렇게 두줄만 적기로 하자.

그럼.. 저 setDB를 이제 우리는 클래스를 만들어야 겠다.



자 가볍게 이런 소스를 적었다고 보자.

그럼 결국 디비에 접속해서 정보를 가져오게 될것이다.

이거야 원 너무 쉬운 이야기라서 참 아쉽기도 하다만.. 문제는 이런 장난같은 함수를 또는 클래스를 만들지 않고 쓴다는게 첫번째 문제이다.



SP를 어떻게 사용하는가 하는 질문도 어디서 본듯한데..

SP의 경우도 별게 없다.



자 이렇게 만들었다면.. 이제는 콤보박스에 바인딩을 연습을 해보도록 하자.

상세한 설명은 링크의 글을 읽어보도록 하고

http://www.devpia.com/Maeul/Contents/Detail.aspx?BoardID=45&MAEULNO=18&no=394&page=1

자 일단은 우리가 만든 테이블에 정보를 넣어야 겠다 그래야 콤보박스에 바인딩 하는것을 보여줄테니 말이다.

insert into combo(viewSeq,Expression,Value,UseBool,Memo,ComboID)

values(1,'첫번째','1000','T','이건 연습이야','TEST1')

insert into combo(viewSeq,Expression,Value,UseBool,Memo,ComboID)

values(2,'두번째','2000','T','너무 귀찮아','TEST1')

…………...

이런식으로 넣고 싶은데로. 데이터를 넣어두자.



이렇게 콤보박스를 하나 더 추가 시키고..

테이블의 정보를 저 콤보박스에 셋팅을 시켜보도록 하자.

DataTable DT = DB.callSQL("select * from combo").Tables[0];

dataGridView1.DataSource = DT;

comboBox1.DataSource = DT;

comboBox1.DisplayMember = DT.Columns["Expression"].ToString();

comboBox1.ValueMember = DT.Columns["Value"].ToString();



이런방식으로 콤보박스가 셋팅되는것을 볼수 있을것이다.

그러면 또 하나의 질문이 나올듯 한데 왜 이렇게 어렵게 콤보박스를 셋팅하는것인가 말이다.

그러게 말이다.

왜 이렇게 어렵게 하는것인지 아마도 잘난척인가 보다. 그저 넘기도록 하자.

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

이상하게 6번글을 적을때 익스플로워가 버그가 생겨서 글이 날라가거나 또는 적지 못하게 되는 상황이 발생했다.

아쉽다.. 내가 적은 6번글에 아쉬움을 뒤로하며

다시 적기도 싫고..

그냥 이번글에는 아래 강현철님 덕분에 그냥 dataset이야기를 잠시 적어보자.

DataSet이란…

게 뭔지는 몰라도 이글을 적는 사람의 입장에서는 거의 예찬론을 펴고 싶다.

이것은 MVC 의 한몫을 하는 매우 중요한 개념을 지니고 있고 또한 그렇게 설계되고 사용되어지고 있다.

(누누히 이야기 했지만 난 MVC가 뭔지 모른다.)

게다가 이 개념덕분에 닷넷의 모든 컨포넌트들이 이것을 지원하기 위해서 다시 만들어지고 또한 잘 지원하고 있다.

게다가 이녀석이 나올때부터 개인적 느낌인지 몰라도 Linq가 나올것을 예언하지 않았나 한다.

다들 잘 알고 있듯이 자바의 하이버네이트라는 ORmapper의 등장이 있음으로 닷넷에 추가될 기능이라든지 자바의 Vector를 좀 색다르게 사용하는 느낌의 dataset이라고 생각할수도 있으나 그것은 아니지 않나 하는 느낌을 많이 가진다.(어라 표현이 이상하다.)

하여간 DataSet의 닷넷의 핵심적인것중 하나임에는 분명한것 같다.

아님 DB코딩에서 그런것이던지..

어디 강좌나 또는 PPT 세미나 등등을 다녀보면 무수히 마샬링과 언마샬링 또는 시리얼라이징

아님 닷넷리모팅 같은 이야기를 하는데

당최 못 알아 들을 이야기들이고..

지금 적는것은 3티어란 글이 아래에 있으니 그냥 하나의 컴퓨터에서 다른 컴퓨터로 이 데이타셋을 넘기는 법을 살펴보자.

이건 계획에 없던글이다. 그러니 대충 대충 적어보자.

http://msdn.microsoft.com/ko-kr/library/system.data.dataset(VS.80).aspx

MSDN에 보면

이런 문구가 있다.

DataSet 및 DataTable 개체는 MarshalByValueComponent에서 상속되며 원격 서비스를 위한 ISerializable 인터페이스를 지원합니다. 이 두 개체는 원격화할 수 있는 유일한 ADO.NET 개체입니다.

말 그대로 원격화를 위해서 이녀석을 만들었고(물론 그 이유만 있는것은 아니다.)

이 녀석을 사용해서 3 tier을 해라는 무언의 암시가 아닌가 싶다.

그럼 이녀석을 가지고 발음도 이상한 마샬링이란 것을 해볼려면 어떻게 해야하는가?

대략 일반적으로 3가지 방법있는것 같은데 흔히들 말하는 Com과 Dcom

그리고 Web Service 같은것들 또는 3.5에서 WCF 를 이용하거나.

마지막으로 기초적인 TCPClientChannel / TCpServerChannel이 있겠다.

이미 하드에 다들 보유하고 있는 MSDN에 적혀 있는것이니 그리 유심히 볼 필요도 없는 심풀한것을 구현해 보자.

http://msdn.microsoft.com/ko-kr/library/system.runtime.remoting.channels.tcp.tcpclientchannel.aspx



이건 위의 링크에 있는 MSDN의 소스를 그대로 복사해 둔것이다.

물론.. 서버도 가동시키고.. 192.168.1.4에는.. TCPServerChannel의 소스를 실행해 두었다.

이것의 실행화면은



이런식이 되는데.. 잘 보듯이 GetCount가 절대로 9를 돌려줄만한 일이 없다는걸 잘 보길 바란다.

서버쪽의 GetCount는



이런식으로 구현이 되어 있다.

즉 서버의 함수를 실행하는것이다.

자바를 배운사람들은 스텁과 스캘레톤을 배운적이 있을건데… 잘 모르겠는가?

그럼 RMI는 ?...

RMI도 사전에 없긴하지만.. 여기는 c#게시판이니 적어보도록 하자.

Remote Method Invocation 의 약자가 RMI인데 쉽게 말하자면 원격에 있는 녀석의 매서드 즉.. 함수를 사용하는것이다.

자 쓸쓸 짜증이 밀려오니.. 다시금.. 다른 생각을 해보자. 은혜를 꼬시던지.

2강에 적은 여자이름이 뭐였는지 사실 기억이 나지 않기 시작한다. 은영이였나?

쩝…

예전에 지금도 있겠지만 이런 프로젝트가 있었다. DES해석을 시도하기 위해서 전세계 PC를 이용하자. 그래서 어쩌고 저쩌고 하는것 말이다.

(설마 DES ?를 모르지는 않겠지.. 쩝.. 왜 이리 예제도 어려운거야 -_-;;)

하여간 이 엄청난 암호화 기법을 역공법으로 해석하기 위해서 현재의 CPU의 형태로 안되니 전세계의 PC의 역량을 빌리자는 프로젝트 말이다. 그럼 다른 PC에 있는 계산 능력을 어떻게 사용해야 한단 말인가? 결국 이 기법이란게 핵심적으로 계산을 할 수 있는 함수가 그 피시에 있고 난 그 함수를 호출하면 되는것 아니겠는가?

조금 어려운가?

에이.. 막판이다. 이런 생각을 해보자.

난 지금 피자가 먹고싶다. 그런데 무슨피자를 시킬지 모르겠다

그래서 피자카타로그를 집어드니

거기에는 콤비네이션이랑 …. 란 그림과 함께 여러가지가 있었다.

난 전화를 했다. <-----------

상대쪽에서 전화를 받았다. 그리고는 나에게 피자를 배달했다.

여기서 내가 보고 있는 피자카타로그는.. 하나의 내가 원하는것(인터페이스, 또는 스텁)

이고 피자가게에서 만든 내가 주문한것을 듣고 피자를 만드는 행위를 하는것(스켈레톤)

그 피자를 나에게 배달하는것 내가 피자를 받는게 결과값을 받는것과 동일하다.

아.. 어렵다. 뭐야 정말.

이게 왜 dataset과 관계가 있고 3tier랑 관계가 있는거야?

그렇다. 아무런 관계가 없다. 그냥.. 심심해서 적어봤다. 하여간 저따구걸 하는 동작을 마샬링이라고 하는데 말이다.

쩝.. 좀 있다 다시 짜장으로 다시 설명을 해보자.

근데 3tier를 왜 설명하고 있는지 모르겠네 이렇게 구현할것도 아닌데 쩝..

괜히 말린것 같다.

아래에 3tier란 글이 올라오니 그게 뭔지도 모르면서 갑자기 설명하고픈 욕구가 생겨나다니 난 왜 이런단순세포일까..

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

일단 소스를 이용해서 getCount함수를 이번에는 return값을 DATASET 으로 받아보자.

Dataset 음.. 하여간 그래야 조금 더 실감이 날 것 같다.



자.. 함수를 아래쪽을 봐라.. 리턴값을 수정했다.

이걸 호출을 해보자.



물론 서버에도 수정해야겠지.

실행결과는



이렇게 나온다.



호출을 XML형태로 뿌려주게 했기 때문이다.

서버에서 dataset을 만들어서 데이터를 저렇게 넣어둔것이다.

이말은 즉.. 서버에서 보내는 dataset을 클라이언트가 받는다는 이야기가 된다.

조금 이해가 오는가?

3 tier란게 사실 별게 없다. 중간에 TCP서버같은 일종의 체팅서버가 떡하니 하나가 있고

다른녀석들이 여기에 접속해서 정보를 받아가는것에 불과하다.

단지 그 정보를 받아가는것이 Dataset으로 받아갈수 있다는것 그게 핵심이다.

(물론 이것은 지금만 그렇다는것이고 실제적으로 후벼파다 보면 EJB같은것까지 여러형태로 사용되어진다.

그러나 지금처럼 DB코딩 그것도 닷넷에서 의 한정적인 입장에서는 dataset을 일종의 다리로 이용해서

정보를 전달하기 때문에 이렇게 설명을 하고 있다. 물론 닷넷에서는 EJB가 아닌  Dcom을 사용해서 처리하게 될것이다만

기초를 알면 저런건... 사전을 찾아보면 될것이다. 물론 사전에 EJB가 없긴 하더라만..)

결과에 나오는정보는 클라이언트 소스의 어디에도 없다는 것이고 결국 저것이 실행된곳은 서버이고 정보를 받는것만 하는것이다.

그럼 왜 클라이언트에도 Getcount란 함수가 있어야 하는가 말이다.

그건 내가 짜장면집에 전화를 걸어서 짬뽕 한그릇 했을때 난 이미 짱뽕이란 개체가 어떤건지 알고 있어야 되는것이 아닌가?...

최소한 그것이 "음식"이란것을 알고 있어야지만 된다는 것이다. 돌려주는 값의 타입을 알아야 시킬것이 아닌가…

이런 개념들을 자바에서는 RMI라고 이야기 하고

개체가 왔다 갔다를 위해서 처리되는것을 마샬링 역으로 언마샬링이라고 한다.

그 내부적인형태를 시리얼라이징 이라고 해서 "개체 직렬화"라고 이야기 하고

그러기 위해서 가장 적당하다는 XML을 통해서 처리하는게 다반사이다.

물론 이 이야기를 더 발전시키면 Com+와 Dcom쪽까지 이야기를 전진해야 하므로 다소 이 DB시리즈 낙서와 너무 이야기가 멀어지므로.. 좀 생략하자.(사실 모른다. 흐흐)

여하튼 3tier라는게 생각외로 그리 어려운건 아니다.(물론 실제적으로 실무에 사용하려면 아직 넘어야 될 산이 많다.)

자 요약을 하자.

1. Dataset 은 직렬화가 가능한 개체이다.

2. 3 tier란게 사실상 비지니스로직을 처리하는 서버에 클라이언트가 접속해서 데이터를 받아오는것에 불과하다.

이정도가 될듯 하다.

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

귀차니즘으로 tcpServerChannel을 찾지 않을듯 하여 아래에 적어둔다.

http://msdn.microsoft.com/ko-kr/library/system.runtime.remoting.channels.tcp.tcpserverchannel.aspx

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

using System.Security.Permissions;

public class Server

{

    [SecurityPermission(SecurityAction.LinkDemand)]

public static void Main()

    {

// Set up a server channel.

TcpServerChannel serverChannel = new TcpServerChannel(9090);

        ChannelServices.RegisterChannel(serverChannel);   

// Expose an object for remote calls.

        RemotingConfiguration.RegisterWellKnownServiceType(

            typeof(Remotable), "Remotable.rem", WellKnownObjectMode.Singleton

        );

// Show the name and priority of the channel.

        Console.WriteLine("Channel Name: {0}", serverChannel.ChannelName);

        Console.WriteLine("Channel Priority: {0}", serverChannel.ChannelPriority);

// Show the URIs associated with the channel.

        ChannelDataStore data = (ChannelDataStore) serverChannel.ChannelData;

foreach (string uri in data.ChannelUris)

        {

            Console.WriteLine(uri);

        }

// Wait for method calls.

        Console.WriteLine("Listening...");

        Console.ReadLine();

    }

}

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

using System;

using System.Runtime.Remoting;

public class Remotable : MarshalByRefObject

{

private int callCount = 0;

public int GetCount()

    {

        callCount++;

return(callCount);

    }

}

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

3티어에 대한 이야기를 적어 볼까 했는데

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1582&page=1

바로 아래에 글이 적혔다. 여러모로 감사함을 전한다.

^^;;

촌장의 눈치가 계속 보이는 덕에 이번 강좌에는 C#코드를 조금 넣어보도록 하자.

계속 낙서만 적다가는 내가 적은글들이 모두 자게로 갈듯 하다.

프레임웍에는 빠지기 어려운것중 하나가 DB 컨넥션일것이다.

DB연결하는 클래스를 간단하게 만들어 보자.

처음 DB에 연결을 하기 위한 요구사항은

1. 오라클이 되고

2. ms-sql이 되며

3. sql 로 코딩이 가능하고

4. Sp로도 코딩이 가능하고 싶다.

하여간.. 자유로운 영혼이길 바랄것이다.

그러한 코딩을 해보도록 하자.

단지 여기서 코딩하는 기법은 정상적이라기 보다는..

비정상적인것에 가까울수도 있고 되도록 소스를.. 안정적(?)이기

보다는 짧게 가는방향을 선택할것이다.

여하튼 시작해 보자.

일단 클래스 디자인은.



이런모습이 일단 나올것이다. 아래의 setDB는 생성자이니.

기본적으로 callSP와 callSQL형태의 두개의 매서드가 존재한다.

기능이야 알고 있듯이 sql넣어서 실행하고 하나는 SP를 호출해서

실행할것이다.

3.5의 링쿠는.. 지금 다루어야 되는 부분이 아니라고 생각하니까. 일단은 2.0

을 기준으로 계속 가도록 하자.

여러가지 형태가 있겠지만. 우리는 간단하게 뭔가의 쿼리를 때리고 결과치를 받기만 하면된다. 물론 조금 더 있다가는 입력하는것도 하겠지만.. 지금은 심풀하게 쿼리내용을 데이타셋으로 받는것에 집중하자.

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

기본적으로 말이다.

닷넷은.. 값을 하나만들고 오는 함수와 reader같은것도 있고

dataset을 채우는것들이 있다.

여기서 우리는 뜬금없이.. 자전거와 오토바이 그리고 자동차에 대해서 이야기를 해보자.

A지역에서 B지역으로 물건을 옮기는데 거리가 100미터라고 생각을 해보자.

가끔 우리는 자전거로 가기가 편한곳이 있고 주차문제로 오토바이를 타기가 유용할때도 있으며

그래도 옮겨야 되는 물건이 많다면 당연히 자동차를 타야한다.

하지만 결론적으로 모든것이 가능한것은 자동차일것이다.

하지만 어떻는가 덩치가 크고 다시 세워두어야 하니 여러모로 귀차니즘이 발생한다.

하지만 반대로 작은데이타던지 큰 데이타던지 무관하게 자동차를 모두 이용하게 한다면 사용자 측면에서는 단일한 인터페이스(?)를 유지시킬수 있을것이다.

물론 어떤업무인가에 따라 많은 모습이 변화되겠지만. 결론적으로 우리가 지금 구상하고 있는 테스트 프로그램에서는

단일한 인터페이스인 자동차(?)를 유지해 보도록 하자.

이말은... 무조건 쿼리를 날리고 dataset 을 얻어오는것을 기본으로 하겠다는 이야기다.

계속 모습이 변하겠지만.. 기본적인 형태를 코딩을 하면



이런 모습을.. 예상할수도 있을것이다.

아니 이런것들로 시작을 하면 머리가 아플듯 하니 일단은 사용에 대해서 좀 더 초점을 두고 구현은 나중에 살펴 보도록 하자.

실제적으로 위의 내용을 잘~~~ 설명을 하자면 우리는 기본적으로

"생성자패턴" 이라고 하는것들에 대해서 한번쯤 이야기를 해야 되기 때문이다.

물론 내가 여기서 가벼운 싱글톤 패턴정도야 이야기 해줄 수 있긴해도 왜 팩토리 패턴이 어쩌고를 떠들게 되고

3티어라던지에 대한 잡설을 펼치게 되었다가는 아마도 너무 코드없는 이야기가 될수도 있기 때문이라고 위안을 삼자.

(당연히 난 모르면서 아는척 하는데 거의 상승의 경지에 이르렀다.)

사용을 어떻게 할것인가가

실제적인 구현에 영향을 미칠것이니.. 우리의 사용법을 편리하게 하는것에 집중을 하자.

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

우리가 클래스를 만들고 객체지향(?)이라는 허접한 단어를 남발하면서 코딩을 하는 이유는 머리쓰기가 싫어서 이다.

클래스를 만드는 이유는 그 자체가 머리를 어떻게 하면 더 안쓰고(?) 코딩을 할까를 머리쓰다가 만든게 그 이유다.

모순인가?.. 머리를 쓰지 않기 위해서 클래스를 머리쓰면서 만드는거 말이다.

세상이 뭐 다 그런거 아니겠는가?

요구사항

자.. DB를 접속을 하고는 싶다.

근데 귀찮다. 그냥 대충 결론적으로 DataSet만 가지고 오고싶다.

입력할것은 select * from 주저리 주저리만 입력하면 알아서 가져오면 좋겠다.

아.. 가끔 sp도 써야 하니.. 이것도.. 인자값만 넣으면.. 알아서 dataset을 가져오면 좋겠다.

아.. 오라클도 되고 ms-sql도 되면 좋겠다.

이정도만 되면.. 좋은거 아닌가?



자.. 위의 요구사항을.. 정리를 하면.. 생성자에 DB가 오라클인지 ms-sql인지를 넣고

Sp호출을 하던지 sql를 넘기면.. Dataset 을 돌려주는 클래스를 설계를 하면

아마도 이렇게 될듯 싶다.

뭘 이딴걸 만들고 있냐고 또 한소리 하는 사람이 있을듯 하여 계속 말하지만.

사용법은

setDB DB = new setDB("Oracle");

dataGridView1.DataSource = DB.callSQL("select * from tab").Tables[0] ;

이렇게 두줄 적으면..그냥 이유없이.. 데이터       



이렇게 될것이라는 거다.

당연히 sql를 두줄로 이렇게 적으면..

setDB DB = new setDB("Oracle");

dataGridView1.DataSource = DB.callSQL("select * from tab").Tables[0] ;

dataGridView2.DataSource = DB.callSQL("select * from emp").Tables[0];



이렇게 된다는것이다.

즉.. 귀찮게 뭔가를 하지 않아도 결과만 가져오기 위해서 우리는..

클래스를 만든다.

그럼.. MS-sql은 어떻게 할까?

setDB DB = new setDB("MS");

dataGridView1.DataSource = DB.callSQL("select * from comboboxt").Tables[0] ;



위와 동일하게 적어주면.. 된다.

모든게 동일하니.. 우리는 쉽게 setDB에 단지 인자값만 조정해 주면 되는것이다.

그럼.. SP는 어떻게 할까?를 또 고민해야 하는데.

이건 인자값을 일단 받아야 한다. 그것을 모두 string으로 통일하는 입장을 가지도록 하자. 왜냐면 나는 당신에게 솔류션을 제공하는게 아니기 때문이다.

그리고 대부분의 경우(80~90%)는 string으로 모든걸 처리하는게 편하다.

예를들어서..

CREATE PROCEDURE yun_test

@one char(12),

@two char(12)

AS

BEGIN

select * from comboboxt where viewseq <> @one

END

이런 sp를 작성했다고 하자. 물론 @two는 사용하지 않지만 인자값을 여러 개 넘기는것을 테스트 하는 모습을 보여주기 위해서 이다.

이것은 이렇게 호출하도록 하자.

setDB DB = new setDB("MS");

Dictionary<string, string> para = new Dictionary<string, string>();

dataGridView1.DataSource = DB.callSQL("select * from comboboxt").Tables[0] ;

para["@one"] = "1";

para["@two"] = "2";

dataGridView2.DataSource = DB.callSP("yun_test", para).Tables[0];



다소 길어졌다.

하여간 이정도면.. 나름대로 ms와 오라클을 쓰고 그리고 sql로도 가능하며

SP도 가능한 편한 클래스라고 생각한다.

아마도 누군가.. 왜 datatable를 사용하지 않고 dataset을 사용했는가를 딴지를 걸수도 있을것 같다.

이런것은 이미 다 말하지 않아도 알것 같긴하지만 그래도 굳이 설명을 한다면

(설명하기 전부터 막 귀찮아 지고 있다.)

예를 들어서 SP를..

ALTER PROCEDURE [dbo].[yun_test]

@one char(12),

@two char(12)

AS

BEGIN

select * from comboboxt where viewseq <> @one;

select * from comboboxt ;

END

이런식으로 바꾸었다고 하자.. 두개의 쿼리문장이 있다면 저것을 한번에 받을때 어떻게 받을것인가?

그렇다. 그래서 데이터 셋으로 받는다.

이런경우는 생각외로 드물게 일어나므로(10%정도) 클래스는 그냥 일반적인 형태로 디자인 하고 있다.

아.. 오라클도 해야되나. ㅠ.ㅠ

오라클을 보자.

오라클은..짜증만땅이다.

나름대로 뭔가를 잘 지켜줘야 하기도 하고 나름대로 괜찮기도 하면서 또 나름대로 피곤하다.

DB로는 참 괜찮다.

연결적인느낌으로는 피곤하다.

를 이야기 할수 있다.

일단… 오라클의 경우 SP호출시 커서로 받아야 되어야 인자값이 늘어나야 한다.

para["one"] = "1";

para["two"] = "2";

para["o_rc"] = "";

para["o_rc2"] = "";

이런식으로 증가하게 될것이다. 받아야 되는 커서를 넣어야 한다.

여기서 "O_"로 시작하면 커서타입으로 되도록 클래스내에 약속을 지정했다.

그리고 SP에도 이것들을 다 설정해야 하는데

CREATE OR REPLACE package types

as

Type cursorType is ref cursor;

end;

형태로 선언을 처리하고..

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

CREATE OR REPLACE procedure yun_test

(

one in varchar,

two in varchar,

o_rc out types.cursortype,

o_rc2 out types.cursortype

)

is

begin

open o_rc for

select * from emp where sal like '%' || one || '%';

open o_rc2 for

select * from emp ;

end;

이런 형태로 커서를 열어주고 처리를 해야한다.

그래서 ms쪽 책을 보면 커서를 사용하지 말라는 이야기를 적어둔게 있던데

DB의 차이 때문에 그런말이 나온듯 하다.

사용법은 동일하다.

setDB DB = new setDB("oracle");

Dictionary<string, string> para = new Dictionary<string, string>();

para["one"] = "1";

para["two"] = "2";

para["o_rc"] = "";

para["o_rc2"] = "";

dataGridView1.DataSource = DB.callSP("yun_test", para).Tables[0];

dataGridView2.DataSource = DB.callSP("yun_test", para).Tables[1];

물론 저렇게 적어서 두번이나.. 디비를 굴리는 코딩은 하지 않을것이라 믿는다.

이건 예제이므로 용서해다오.. 두어줄 더 적는것도 귀찮다.

하여간.. Sp에서 많은 커서를 넘긴다면.. Dataset을 public으로 하나 두는것도 좋을듯 싶다.

지금은 그렇게 하지 않는다.



물론 세부적인 세세한 것을 더 작성한다면 더욱좋겠지만.. -_-;; (이건 솔류션이 아니라고 …~~~~!!! 단지 낙서야 낙서)

테이블이름을 매칭을 시킨다던지 하는것들 말이다. 그런건 알아서 하기 바란다.

개인적인 이야기지만 대략 지금의 기능을 구현하는데 클래스 하나에 100여줄 코딩으로 끝나지만..

세세한 기능을 다 주고 에러처리에 몇몇가지를 추가하면 여러가지 클래스를 만들어야 하며 몇몇가지 Adapter적인것과 Interface적인 녀석까지 추가해서 만든다면 전체 코딩이 1000여줄이 넘어설것이다.

그러니 그냥 가자.

간단히 가기위한 몇몇가지 방책들..

1.

심풀하게 이녀석은 singleton도 구현하지 말고 그냥.. 무식하게 static connection 하나로 버팅기는 식으로 코딩을 하자.

2.

낙서에는 기본적으로 try ~ catch같은걸 적는걸 배제하는 이유는 소스가 길어지기 때문이다.

3.

인자값은 무조건 스트링 리턴값은 무조건 데이타셋이다.

에러가 뜬다면.. 질답란에 질문을 하면

답변을 달아줄 사람이 부지기수니 잘 물어보기만 하면 될것이다.

저짝에 벌써 손들고 SP에 인자값 없어도 되는 오버로딩도 하나 추가해달라는 사람이 보인다. 그런건.. 제~ 발 알아서 하기 바란다.

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

자 일단은 테스트를 위해서는 우리는 서버가 필요하다.

일단 ms-sql은 xp에 설치가 되지 않기 때문이고 또한 자신이 사용하고 있는곳에 오라클이든지 ms-sql이던지

설치를 하게 되면 상당히 PC가 느려지기 때문이다.

그래서 해답(?) 스스로 찾아야겠지만.. 나의 경우는 버추얼 PC를 사용해서 주로 돌리게 된다.

Virtual PC 2007는 무료로 MS에서 제공하니 MS에서 받도록 하자.

DB의 코딩에 있어서..

버추얼 PC 는 거의 필수에 속한다.

예전에 머리속에 아무것도 없을때는 그냥 컴퓨터에 오라클도 설치하고 ms-sql 거기다 my-sql 까지 설치를 했었다.

갈수록 컴퓨터는 느려지고 뭐가 그리도 충돌도 심한것이 많은지

나중에는 서비스에 중지를 한다거나

잘 제거도 안되는 오라클 덕분에 레지스트리를 뒤지다 실수까지 해서 OS를 다시깐 에피소드도 있다.

게다가 ms-sql은 서버에만 설치가 된다.

그럼 해답은 무엇이겠는가?

바로 버추얼 PC가 그 해답이다.

이 글을 적는 입장에서

하나는 2003을 설치를 하고 다른 버추얼피시에는 XP를 설치해 두고

2003에는 ms-sql을.. Xp에는 오라클을 설치해 두었다.

이것은 개인적 사정이고 하나의 버추얼 피시에 두개의 sql을 다 설치해도 좋다.



설치를 한뒤에

각각의 버추얼 형태로 ms-sql과 오라클을 설치해서 그것을 start하게 되면 하나의 sql서버가 돌아가게 되는것이다.

물론 각자의 취향이니 이건 단지 DB 코딩을 위한 하나의 준비라고 생각하자.

알아서 SQL 서버를 하나씩 준비해 두자.

자 여하튼.. 서버에 접근해서

우리의 ERD를 위한 DB에 계정부터 만들어야 겠다.





에 가서..



을 선택하여.. 로그인을 만들자.



그런다음 ER-win에서 DB접속을 해서 우리가 만든 테이블을 넘기면 되는것이다.



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

중간 단계를 많이 생략하면서 적는데 실제적으로는 참 귀찮은 작업들이 많다.

오라클도 알아서 준비해 놓자.

만약 이 중간과정에 대해서 더 관심이 있다면 네이버나 구글에 ER-WIN이라고 입력해서 알아보길 권한다.

CREATE TABLE Patient

(

PatID nvarchar(8) NOT NULL ,

PatNM nvarchar(10) NULL ,

PatRegDate           datetime  NULL ,

PatNAN char(13) NOT NULL ,

PatSex numeric(1) NULL ,

PatBirth             nvarchar(8)  NULL ,

PatMemo nvarchar(4000) NULL ,

PatFaceImage image NULL ,

PatRFID nvarchar(50)  NULL

)

Execution Successful

ALTER TABLE Patient

ADD CONSTRAINT XPK환자 PRIMARY KEY CLUSTERED (PatID ASC)

Execution Successful

자 이렇게 자동으로 테이블을 만들어서 실행까지 해줄것이다.

또는 직접 디비에 접근을 하지 않더라도 위의 스크립만 만들어서 날려줘도 좋다.

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

DB 3를 보면서 DBase III와 DBF를 생각한 사람은 정말 이글을 안봐도 되지 않을까?

자 네번째 글이다. 아무래도 촌장의 눈치가 보인다.

강좌란에 낙서로 도배를 해야되는 입장에서 이번글에는 조금 딱딱하게라도 뭔가 있는척 해보도록 하자.

뭐 원래는 여전히 우리 은영이의 전번에 대한 이야기를 적어야 되지만 촌장이 여간 만만치 않은 인물이므로 방향을 틀어서…

업무분석단계에서 의사 선생이 요구한것은

마치 중국집의 "배달왕" 같은 프로그램 처럼 전화가 걸려왔을때 그사람의 신상정보가 떡 하니 뜨는것을 요구했다.(아마도 저 배달왕이란걸 이해 못할건데 중국집을 연상하면 된다. 요즘 중국집에 전화를 걸어서 짜장 하나요 그럼 네 하고 끊지요.. 저의 집주소를 이미 알고 있는거죠)

즉 전화기의 CID를 받아서 그것을 DB에서 쿼리한 다음에 그 정보를 화면에 보여주는것이다.

그때에 나타나야 하는정보는 피부관리 횟수와 각종 수술정보 그리고 방문시 마다 나아진 모습의 사진을 볼수 있어야 된다는게 요구사항이다.

핵심은 결국 CID를 받는것이고 그것은 장비가 해줄것이니 지금 초점은 DB의 설계를 어떻게 할것인가이다.

일단은 기초요구사항중 하나인 전화기록이 모두 남게 해달라는것(즉 테이블이 하나 더 필요할것이다.)

그 전화들마다의 메모를 적을수 있도록 해달라는것과 의사에게 전달할수 있도록 체크박스를 해서

다음 진료일에 그 메모가 전달되도록 해달라는것이였다.

고객의 전화번호가 여러 개 일경우라도 모두 인식하게 해달라는것(이건 정말 곤란하다.)

게다가 마찬가지로 고객의 주소지가 변경이 되어도 모든 주소지의 내역을 저장해 달라는것이다.

예를 들어 직장, 집, 전직장, 등등…

이런 황당한 요구사항들을 다 들어주게 된다면 프로그램은 여간 피곤해지는게 아니다.

일단은 딱 짤라게 겠지만 지금은? 그렇다 우리 은영이를 위해서 못해주는게 뭐가 있겠는가?

(그러다가는 프로젝트 말아먹는다.)

하지만 알게 뭔가.. 지금은 연습하는거 아니겠는가?

우편번호 테이블도 귀차니즘으로 생략을 하고 위와같은 대충 테이블을 생성하자.

헉.. 이말을 적음과 동시에 ER-win을 설치해야 한다. 베타버전은 알아서 받기 바라며

설치 ㅠ.ㅠ

하여간.. 지금 사용할것은 7.X 버전을 이용해 보도록 하자.

( 4.X버전은  ms-sql의 2000 그리고 oracle의 9.0까지 접속을 처리해주고 상위버전으로 접속을 해보질 않았다.)

( 그 이후 7.X대는 ms-sql의 2005 oracle의 10G/11G까지 처리가 된다. )

( 이 글에서는 ms-sql 2005와 oracle 9i 를 사용하는것을 기준으로 하자. )

방금 2강에 낙서를 적었음에도.. 사실 내가 뭘 적었는지 기억이 나지 않는다.



하여간 이때까지 적은걸로 대충 만들어 보면 이와 유사한 테이블이 될듯 싶다.

너무 복잡하다. ㅠ.ㅠ 내가 하기에는 조금 힘들듯 싶긴하지만 계속 해기록 하자..

(물론 위의 테이블은 딱 보기만 해도 정규화 1NF 의 위반을 가지고 있다. 이런걸 지금 설명하기에는 여러모로 버거우니

이야기가 진행되어가면서 여유가 될때 이야기를 해보자.. C# 강좌에 DB이야기 까지 영역이 늘어나서 지금 적어야 되는 이야기가 너무 많다. ㅠ.ㅠ)

일단은 설계도란건 여러가지 상황을 고려해야지만 한다. 예를 들어서 전화번호와 전화내역은 그림에서 보듯이 널이 허용되는 연결을 가진다.

이것은 즉 걸려온전화번호가 이미 저장되어 있는 전화번호가 아닌것도 전화내역을 저장하기 위해서 이다.

항상 새로운 전화번호가 대부분일것이며(?) 그러한 신규환자가 있어야지만 좋은것이기 때문일것이다.

그리고 그에 따른 메모를 잘 해두고 다음에 이런 신규환자(?) 상담환자가 다시 전화를 했을때 그 상담내역을 알수 있다면

업체의 경우는 여러모로 좋을것이다.

자.. 그러니까.. 문제의 핵심은 create를 대신 만들어 주고 이것을 따로 파일로 관리해주고 그림으로 쉽게 알아 볼수도 있으니 그래서 이런 툴을 사용하게 되는것이다.

하여간.. 우편번호 테이블을 만들어야 되고 연결도 해야되고.. 각 필드마다의 사연(?)을 이야기 하면서 잘 지워가기도 하고

또 새로운걸 넣기도 해야겠지만.. 지금은 그냥 두자.

나중에.. 수정하도록 하자.. 여하튼 지금은 적당히 하고 하여간.. 저 테이블 중에서도..

정말.. 생각없이 만든.. 첫번째것만..

이야기를 시작해 보도록 하자.



방금 몇가지 수정을 처리했다.

DB에 대한 여러가지 필드에 대한 이야기는 아마도 C# 게시판에 적을글이 아니니

예제를 위한 형태로 코딩을 하면서 계속 필드를 넣거나 빼도록 하자.



자 물리테이블을 대충 설계를 하고.. 물리테이블을 위해서는 우리의 경우 오라클과 ms-sql을 둘다 해야 하므로

사실상 ER-win 파일을 두개를 만들어야 한다.

위의 경우는 ms-sql의 경우가 될것이다.

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

DB2라고 적힌글을 보면서 IBM을 생각했다면 당신은 이글을 안 봐도 좋지 않을까?

이제 목차를 적어보자.

과연 뭘 적을지 모르겠지만 긴 글을 적을때 가장 중요한것은 목차의 선정(?)일것이다.

일단은 내가 할것은

시리얼로 전화번호 CID 를 받을것이다.

또한 시리얼로 RFID 의 UID를 받아서 처리해야 할것이며

전체 폼의 DB셋팅을 처리해 주는 루틴을 위해서 foreach를 돌릴거고

MS-sql과 Oracle을 처리할것이고

디비에 이미지를 넣고 빼고를 해야되어서 CLOB / BLOB그리고 ms-sql의 image를 이용하자.

SP 형태와 그냥 SQL형태 둘다 처리하는 루틴을 짜고

Dataset에 대한 이야기와 이것을 다루는 LINQ을 살짝 찍고

전체 프로젝트에 대한 ER-win으로 데이터 설계를 해야하며

부수적인 컬랙션이라던지 XML이라던지 등등을 이야기들을 하면서

시간이 된다면 아래의 적은 Spread와 크리스털의 이야기의 후반부도 완성해 보자.

그리고 닷넷의 기초틀을 이루고 있고 현재 적어야 되는 이야기에서 빠질수 없는 패턴중에 생성자 패턴에 대한 이야기들을 잠시 풀어야 될듯 싶다.

Sql서버가 있어야 되니 이것을 구축하는걸 위해서 어쩔수 없고 버추얼 PC이야기도 잠시 할수도 있고 말이다.

너무 많나..

-_-;;

그렇다. 결국 난 '구라'로 시작하여 '구라'로 끝나는 강좌를 적을것이다.

이글의 제목을 봐라 '낙서' <--- 낙서라함은 문학계에서 수필의 최상위권에 있는 형식으로서 있거나 말거나 또는 믿거나 말거나의 문학이라고 내가 정의한다.

그러니 당신이 낚였다고 생각을 하거나 말거나 난 크게 개의치 않는다.

코드한줄없이 벌써..2강이지 않는가 우하하~~

조회수를 보면 역시 1강의 최고의 조회수를 자랑하며 결국 갈수록 떨어지는 조회수를 보게 될것이다.

물론 촌장이 이글을 자게로 옮길까 겁나긴 하다.

자… 무엇부터 시작을 해야 하는가?

What to do or Not to do that is question

가상의 꿈을 꾸도록 하자.

어느날 성형외과에서 자신들의 환자의 이미지들을 잘 유지관리하도록 하기 위해서 나에게 프로그램을 의뢰하였다.

이제 그 성형외과의 관리 프로그램을 하나 작성해 보도록 하자.

자 사람이 왔다. 의사가 어쩌고 저쩌고.. 간호사가 어쩌고 저쩌고를 하는데 어찌 그리 이쁘던지

하나도 기억이 나지 않는다.

늘씬하게 빠진 다리만 보다가 당신은 정신을 놓았다.. ^^;;; 헬렐레….

된장.. 테이블을 만들어야 하는데

오로지 그녀의 이름만 생각이 나고 말이다. 하지만 성과는 있었다는거 전번을 따고야 말았다.

Create table xxxx

이름

전화번호

그녀의 키

그녀의 몸무게

그녀의 집주소

어라 sql이 에러를.. 이게 어떻게 적더라.. Sql책을 뒤적 뒤적

젠장.. 하나도 기억이 나지 않는다.

이런 여자에 정신이 팔리니 creat쿼리 하나 기억이 나지 않는다니 말이다.

에이 정신도 산만해서 그녀에게 전화를 걸었다.

뚜~~~

여보세요.. 저 최은영씨 좀 부탁합니다.

네 전데요.

네.. 어제 만나뵈었던 프로그래머입니다.

몇가지 궁금한 사항이 있어서요.

네 물어보세요.

혹시 남자친구는 있으세요? 라고 묻고 싶었다. ㅠ.ㅠ

"남자"…..

까지만 말을 하고 그만 아무런 생각이 들지 않는것이다.

"남자들도 성형하러 오시나요?"

"네 당연하죠"

그녀를 자주 봐야겠는데 이런 자주 들러야 겠다.

"혹시.. 내일…"

"네..?"

"내일도 출근하세요?"

"네 그렇죠. 그게 프로그램과 무슨상관이 있죠?"

"아… 네.. 그게 그러니까 출퇴근하는것을 기록해야 하거든요. 의사선생님께서 말씀을 하셔서"

"아.. 네.."

"네.. 그럼 궁금하게 있음 다시 연락드리겠습니다."

아 참 이런 바보같은 질문을 떤지고야 말았다.

왜 난 sql도 기억이 나지 않는가?

그녀의 생일도 묻고 싶었는데…

아 어떻게 하면 그녀의 사진이라도 하나 껀질수 있을까?

머리를 굴려봐도 답이없다. …..

이런 … 차분하게 다시금 테이블을 작성해 보자.

일단은

이름을 알아야 하고

주민등록번호.. 그렇다. 이걸 알면 생일신공은 자동빵이 아닐까?

이런 음력생일일수도 있는데

이여자가 여길 언제부터 일했을까?

증명사진을 DB에 넣어야 된다고 뻥치고 사진을 좀 얻어야 하나

출퇴근을 알아야 하니 RFID도 필드에 넣어야 될듯 싶다.

남자도 오긴 한다고 했으니 남녀 구분필드도 만들까? 아님 주민등록번호로 그냥 할까?

자 이런 생각을 하면서 다시금 create를 적으려 했으나 눈물이 앞을 가린다.

그래서 말이다. 정말 그래서 ER-win이란게 만들어 졌다.

어떻게 하면 여자를 잘 꼬실수 있는가 하는 고민을 하다가 누가 이런 프로그램을 만든것이다.

자 우리는 여자를 꼬시기 위해서 ER-win이란걸 구해서 사용해 보자.

왜냐? 내가 그래도 뭔가 하는듯 보여줘야 할거 아닌가? 가끔 건축하는사람들이 AutoCad를 사용해서

설계도를 가지고 와서 내가 알지도 못하는 이야기를 할때마다 가끔 뭔지는 몰라도 뭘 하는가 싶네 하지 않은가? 그렇다. 우리도 그런 설계도 비스무리 한걸 만들어서 이 여자 앞에 떡 하니 깔아놓고 뻔뻔하게 이제 사소한걸 물어봐야되지 않겠는가 ? 어디사세요?

"왜 그런걸 물어보세요?" 라면.. 여기 있잖아요.. 여기에 다 넣어야 되어서 그렇다고

얼른 '구라"를 치는거다.

물론 그래도 믿지 않는다면.. 주소란에 최대치의 글자를 얼만큼 넣어야 되는건지 알아야되어서 그렇다고 얼른 모르는 소리를 하면서 varchar이 어쩌고 상관도 없는 Blob이 어쩌고를 떠드는것이다.

알게 뭐냐.. Binary Large of block인지 라고 전산쟁이가 보면.. 이녀석 사기치네 Large object를 가지고 사기도 좀 잘 쳐라 싶기도 하지만..

물론 심각한 표정으로 정말 그렇다는듯이 말이다.

아 저기서 누가 ER-win이 여자를 꼬시는데 전혀 도움이 안된다고 의의를 제기 하는데 일단 그 증거를 보여주겠다.



최대한 복잡하게 그려가는거다.

좀 있어보이게 그리고 나서 하나씩 여기 빈곳을 다 채워야 된다면서 사방팔방 물어보는거다.

아 저기 뒤쪽에 왠 뜸끔없이 이런 그림이냐고 그러는 사람이 있는데

만약 이런거라도 안 올리면 c#관리자가 이글을 자유게시판으로 옮겨 버리는수가 있기 때문이다.

눈치것 살아야지 말이다.

하여간 위의 그림은 c# 마을의 관리자를 위한 눈속임(?)이고.. 이제 우리는 다시 본업(?)의 자세로 돌아오기로 하자.

하여간 문제의 핵심은 내가 create구문이 생각이 안난다는거였고

두번째로는 좀 있어보이게 해야된다는거와

세번째는 적지는 않았지만.. Create를 계속 위의 테이블처럼 어트리뷰트가 많은걸 적게되면 나중에 이게 뭐가 뭔지 모르게 된다는게 핵심이다.

그래서 그려야 하는데

그리는 툴로 대표적인게 ER-win이란것과

국내에서 만든걸로는 이화식이란 분의 회사의.. (엔코아의 DA#.) 나온..툴이 있다.

그외 기타등등은.. 댓글다시는분이 상세히 적어줄것이다.

뭐 백수인 난 잘 모르는거고 현업에 계시는분이 잘 알고 있으니 모르면 네이버나 구글신에게 물어보길 바란다.

참 여자 하나 꼬시는데 험난한 일정이다.

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

어느날 문득 글을 적고 있는 나를 보게 된다.

 

왜 적는지 이유는 있기도 한듯 한데 그걸 나도 알수가 없다.

 

세상에 나와 잘난 허영심때문인가?

 

하여간 이 글이 아마도.. 아니 사실상 여기 게시판과는 동떨어진 이야기가 될듯 해서

심히 촌장에게 미안하긴 하다만.

 

그래도 자주 낙서를 적는곳에 적는게 왠지 나름 편하게 느껴지는 덕에 여기에 계속 낙서를 적어본다.

 

 

자 처음 만들어 보는 DB 프로그램을 해보도록 하자.

처음만들어 보는것이니 많은 오류가 있을것을 예상하며.. DB코딩에 익숙하지 않은 프로그래머이니..

현업분들의 많은 수정과 지적을 부탁드린다.

 

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

 

이 글을 적게된 시작은

foreach에 대한 허접한..

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1568&page=1

 

이야기를 적었음에도 여전히 질답란에는 동일한 질문이 넘쳐나고 아마도 이런류의 질답은 백여개가 휠씬 넘는데 말이다.

 

활용법을 모르는게 아닐까 하는 생각이 들고 MVC적인 형태는 어떻게 적용되어야 할까 하는 이야기를 해주고 싶기도 해서이다.

 

그런 와중에

최근에 본 combobox에 바인딩.. 질문

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=17&MAEULNO=8&no=99294&ref=99294&page=2

 

이런 질문들도 보여지고 해서 왠지 여타 저타한 이야기들을 적어봄직하다고 생각이 들고

 

또.. 아래 강좌중에

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=18&MAEULNO=8&no=1576&page=1

이글을 보다가.. 내가 하기에는 버거웠기 때문이도 하다. 좀 다른 생각을 해볼까 해서 적어보기도 한다.

 

뭐… 여러가지 사유가 있겠다.

 

 

글의 서두에서 이야기 했듯이 그렇다고 내가 더 많이 알거나 또는 더 좋은 방법이 있다는것이 아니라.

단지 생각이 다를뿐이란걸 강조하고 싶다.

 

 

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

 

 

아마도 학교에서 또는 학원에서 아님 현업에서 수많은 아니 귀찮을 수준으로 MVC를 이야기 하는데도 불구하고 코딩은 여전히 그것은 별나라 이야기가 되어가고 있다.

MVC 는 별나라 이야기이고.. 그게 뭔데? 그렇다. 느껴지지 않으니 그것은 단지 책에만 적힌 이야기일 뿐이다. 당최 저걸 구현해 보려고 생각도 안하고 그저 그것은 별나라 이야기거니 하는게 더 문제가 아닐까?

 

그럼 난 아는가? 아니 능력없는 백수가 뭘 알겠는가?.. 난 서두에도 밝혔듯이 취직도 안되는 백수에 불과하다. 나 취업 좀 시켜주라. -_-;;

 



어느 프로젝트에 가보면.. 위와같은 모습이 보인다. 물론 저것보다.. 열배정도는 더 복잡하고 더 많다.

 

뭔말로 공통모듈이고 그냥 뭔가를 구현해 놓은 class는 하나도 없고 당최 Form파일들만 가득가득하다 물론 이름은 위와 다르겠지만..

뭘 하자는건지 말이다. 그 폼파일을 열어보면 어떻게 생겼을것 같나. 하나같이 같은 코드 또 적어 놓고 또 적어 놓고 소스가 천여줄을 넘어 심지어 만여줄까지 가는 폼들이 생겨나고 있다.

 

아마도 이때까지 내가 적은글들이 대부분 100여줄 수준에서 깔짝거리는거에 비하자면 정말 고수들의 잔치인지. 왜 그리도 소스가 길게 적는건지 모르겠다.

 

마치 길게 적어야지만 있어 보이는건가?

 

아니 Static은 쓰면 사망인가?

그럼 Math클래스에 있는 static남발들은 생각없는사람들이 만든 코드인가?

왜 객체지향이고 Class를 만든건 하나도 없고 오로지 Form Class에 Mathod만 늘어가고 있는것 같지 않은가?

 

하여간 이런것들은 단지 푸념이고 나도 그들과 동일하게 똑같이 코딩을 하고 있으니 결코 저말이 다른이에게 이야기 하는것은 아니다.

 

MVC 란게 무슨 약자인지도 모르니 걱정할 필요없다. 게다가 내가 저걸 설명할 능력도 되지 않은다.

 

하지만 이렇게 생각을 해보자.

 

난 폼을 대충 드레그 드랍으로 떨구어 놓고

 

알아서해(this)

 

요렇게 한줄 적어버리면 모든게 다 되면 얼마나 좋을까?

그런 상상을 해본적이 없는가?

자동으로 DB와 연결되어서 택스트 박스면.. 내용이 콤보박스면.. 콤보를 채워주고

스프레드면 스프레드의 내용이 나오도록 말이다.

 

그럼 폼에 코딩하는게 100여줄 이내가 되지 않을까?

 

난 그런 코딩을 해야된다고 생각한다. 1000줄이 뭐냐.. 심지어 만줄이 넘어간다는것은 어쩌면 우리가 코딩을 잘 못하고 있다는 지표가 될수도 있음을 알아야 한다고 본다.

당최 어느세월에 그걸 다 해석하고 있고 어느세월에 그걸 다 수정해주고 있는가 말이다.

 

Ps) C#책에 한페이지도 안되는 foreach로.. 난 몇페이지나 우려먹고 있는거야.. 정말.

Ps2) 그런데 MVC 가 뭔지 영어사전에도 안나오더라.. ㅠ.ㅠ 나 괜히 아는척 했다.

 

 

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

 

인간이 호랑이를 죽일 때는 그것을 스포츠라고 한다.

호랑이가 인간을 죽일 때는 사람들은 그것을 재난이라고 한다.

범죄와 정의와의 차이도 이것과 비슷한 것이다.

- 버너드 쇼

난 심각한 편견을 가지고 있는지도 모른다.

얼마나 웃었는지 모르겠다.

결코 유머는 아닐진데.. 왜 웃음이 나는지 모르겠다.

출처 : http://playtalk.net/oisoo/

(오늘의 발견)방금 AveMaria를 AviMaria로 읽었다. 아베마리아와 야동마리아 사이에서 갈등을 때리는 1人. 

그대가 이름을 모른다고 산야에 피는 풀꽃들을 모두 잡초라고 생각지는 마세요

천재들은 이따금 '다른 답'을 창출해낸다. 그러나 무식한 채점관들은 '다른 답'과 '틀린 답'을 구분하지 못한다. 그래서 한순간에 천재를 둔재로 전락시켜 버린다.

(세기를 초월한 대화) 소크라테스가 말했다. 너 자신을 알라. 친절한 금자씨가 되받아쳤다. 너나 잘 하세요. 

세상은 단지 돈이 되지 않는다는 이유 하나로 돈보다 소중한 것들을 시궁창에 내던져 버리기 시작했다. 양심이나 철학도 그 중의 하나다.

유능한 조련사는 말을 물 가에까지 끌고 갈 수도 있고 말에게 물까지 먹여 줄 수도 있다. 그런데 말이 싸가지가 없어지면 조련사가 오줌까지 대신 싸 주지 않는다고 투덜거린다.

먹고 싶을 때 먹을 수 있고 자고 싶을 때 잘 수 있으니 나는 정말로 행복하다. 그리고 이 행복은 바로 먹고 싶을 때 먹지 못하고 자고 싶을 때 자지 못했던 젊음에서 유래된 것이다.

일반 커뮤니티에서 때로 타인의 기분은 생각지도 않고 자신의 감정이나 주장만을 함부로 배설해 버리는 미숙아들이 있다. 자제를 요청하면 왜 다양성을 수용하지 못하느냐고 힐난한다. 하지만 아놔 즐, 다양성이 곧 정당성은 아니다.

마음에 들지 않는 인간을 만나면 그래, 산에는 소나무만 살지는 않으니까, 라고 생각하면서 위안을 삼는다. 

(지대공감 자작속담) 악플 끝에 살인나고 친플 끝에 정분난다 

(지대공감 한국속담)무식한 귀신은 부적도 몰라본다