Taeyo's ASP.NET
|
|
강좌 최초 작성일 : 2004년 07월
13일|
강좌 전 태오의 잡담> 드디어 태오 사이트 .NET 버전의 알파 사이트가 완성되었습니다. 약간의 테스트를 거치고, 8월 중에는 베타 사이트를 오픈해 보도록 하겠습니다. 많이 격려해주세요 ^^. 감사합니다.
이번 시간에 같이 다루어볼 내용은 중급 .NET 개발자로의 도약을 위해서 알아두어야 할 Microsoft Data Access Application Block에 대한 이야기입니다. 아마도, 아직까지 Microsoft Data Access Application Block에 대해서 모르시는 분들이 많으실텐데요. 나온지가 꽤 된 것으로 알고 있습니다만... 이를 사용하시는 분들이 아직까지는 그지 많지 않은 듯 하더라구요. 사실, 이건 우리끼리 이야기인데요... 이 기술은 말입니다. 주로 .NET 컨설팅 회사들이 프로젝트 들어가서 프레임워크 작업할 때 주로 참고하곤 하는 녀석이랍니다. 사실 기존에 그렇게들 많이 작업한 것으로 알고 있거든요. 물론, 믿거나 말거나지만... 어쨌든, 이렇게 말씀드리니깐 뭔가 고급스러워 보이고, 뭔가 대단한 것 같지요?? 그러면서, 슬슬 구미가 당기기도 하실 겁니다. 하하하.. 일단, 그렇다면, 1차 꼬시기 작전은 대성공인걸요~~~ ^^; 그렇다면, 일단, Microsoft Data Access Application Block라는 것이 무엇이냐? 부터 시작해 보도록 하겠습니다. Microsoft Data Access Application Block 란? 일단, MSDN에 있는 MDAAB의 정의를 한번 같이 살펴볼까요?
영어라고 무조건 이해하지 않고 넘어가려는 자세는 위험합니다. 현대 개발자들이라면 영어에 대한 거부감을 지금부터라도 접으시고, 과감하게 도전하시려는 자세를 가지셔야 합니다. 영어를 못하면 공부를 해서라도 알아야만 개발자로서 미래를 바라볼 수 있는 시대가 이미 되었으니까요. ^^. 그렇다면, 태오는 과연 영어를 잘하는가??? 그에 대한 대답은 자신있게 드릴 수 있습니다. 여러분~~ 우리 같이 공부해요~~~ -_-; 우선, 위의 이야기를 간단하게 정리하자면 다음과 같습니다. MDAAB는 .NET 기반의 어셈블리이구요. Microsoft SQL 서버를 대상으로 해서, 일반적인 데이터 접근 작업을 할 경우에 매우 유용한 기능들을 정리해 둔 유용한 컴포넌트 블록입니다. 이것을 사용하게 된다면, 여러분은 데이터 접근을 위해 일반적으로 사용하는 ADO.NET 수행 코드를 상당량 줄일 수 있게 되구요. 코드도 뭔가 깔끔하게 정리되고 일관적인 상태로 구성할 수 있게 됩니다 동일한 데이터 액세스 코드를 반복해서 쓰는 것이 불합리하다고 느껴본 적이 있다면, Microsoft Data Access Application Block은 그러한 문제의 멋진 해결책이 될 수 있을 것입니다. 단돈 39,800 인 잭삘두 바지보다도 더 감동적이며, 엘레강스하고 빤따스띡하지요. 쉽게 말하자면, Microsoft Data Access Application Block를 사용한다는 것은 여러분이 데이터베이스 관련 작업들을 아주 쉽게 처리할 수 있도록 도움을 주는 특별한 도우미 클래스를 사용한다는 것과 같은 의미입니다. 웹 어플리케이션의 논리적인 다중 계층 중 어느 계층에서던 말입니다(하지만, 가급적 Data 계층에서만 사용하는 것이 추천됩니다. 요부분은 밑에서 상세하게 설명드리겠습니다). 이해가 잘 안 가실지 몰라서 샘플 코드를 준비해 보았습니다. 다음 코드는 가상 코드(pseudo code)인데요. 여러분이 직접 ADO.NET을 이용할 경우와 Microsoft Data Access Application Block에서 제공하는 도우미 클래스인 SqlHelper를 사용하실 경우의 차이를 보여드리고 있습니다. 일단, 한번 눈으로 비교만 해보세요. 코드가 확연하게 차이가 나지요???
어떤가요? Microsoft Data Access Application Block을 사용할 경우, 즉, Microsoft Data Access Application Block의 대표 클래스인 SqlHelper 클래스의 정적 메서드를 사용할 경우, 데이터베이스 작업은 단 한줄로 끝나버립니다. 정말로 Cooooool 하지 않습니까??? SqlHelper 클래스가 가진 기능은 실로 대단합니다. 수 많은 메서드들이 제공되고 있어서, 여러분이 원하는 대부분의 데이터베이스 관련 작업들을 불편함없이 수행할 수 있을 정도입니다. 멋지죠? 다음 그림은 MSDN에서 제공하는 Microsoft Data Access Application Block의 개략적인 개요입니다. 참고로, 저는 이 그림을 제 노트북의 윈도우즈 바탕화면으로 깔아놓고 있기도 하답니다... 클래스의 설계는 대략 이래주어야 한다는 교훈을 삼고자... -_-;;;
SqlHelper 클래스는 마치 ADO.NET에서 DataReader나 DataSet이 제공하던 메서드들과 거의 똑같은 이름으로 메서드들을 제공하고 있기에, 그 메서드의 역할이나 사용법을 우리(ADO.NET을 좀 공부한 우리)가 이해하기 대단히 쉽습니다. ^^; 이 클래스의 구체적인 메서드들 목록 및 시그너처에 대한 정보는 Microsoft Data Access Application Block를 설치할 때, 같이 설치되는 도움말(Documentation)을 참고해 보도록 하세요 ^^ 또한, Microsoft Data Access Application Block의 가장 큰 장점이라면... 놀랍게도... 위에서 설명한 모든 것에 대한 소스를 아낌없이 공짜루 제공해 준다는 점입니다. 그것도 C# 버전과 VB.NET 버전 모두를 말이죠. 다시 말해서, SqlHelper 클래스의 소스를 직접 까 볼수(!) 있다는 것이고, 그 소스를 참고로 여러분의 클래스 설계 내공 향상에 큰 도움을 얻을 수도 있다는 것입니다. (그 클래스를 재편집하여 사용하는 것은 MS에 문의해 보셔야 할 것입니다. 소스에 보면 떡하니 Copyright가 걸려 있더라구요 ^^) 그렇다면, Microsoft Data Access Application Block은 어디서 다운로드를 받을 수 있을까요? 두말하면 잔소리. 마이크로소프트 사이트의 다운로드 구역에서 다운로드 받으실 수 있습니다. 하지만, 그보다는 다음의 경로가 더 나을 것입니다.
위의 링크는 Microsoft Data Access Application Block에 대해 자세하게 소개하고 있는 MSDN 컬럼입니다. 기쁘게도 한글로 번역되어져 있습니다.!! 그렇기에, 여러분들이 반드시 읽어봐 두어야 할 글이기도 하지요. 또한, 직접 다운로드 받으시려면 다음 링크를 눌러주셔도 좋습니다
위의 컬럼에서 여러분은 Microsoft Data Access Application Block을 다운로드하여 설치할 수 있을 뿐만 아니라(설치라고 해봐야... 단지 파일카피의 수준이긴 하지만), 이것의 개요. 필요성, 사용 방법등을 배우실 수 있을 겁니다. 일단 설치를 끝내고 나시면, 윈도우즈 메뉴 중 프로그램에 다음과 같은 메뉴가 추가된 것을 보실 수 있을 겁니다.
소스 코드 뿐만 아니라, 퀵 스타트 샘플도 제공하고 있지요. Microsoft Data Access Application Block을 사용하는 예를 보고 싶다면, 반드시 퀵 스타트 샘플을 실행해 보도록 하세요. ^^ 여러가지 유용한 예제들이 들어있으니까요 ^^. 일단, 우리의 경우는 그 퀵 스타트 샘플과는 별도로 Microsoft Data Access Application Block를 사용하는 예제를 간단하게나마 한번 진행해 보도록 하겠습니다. ^^
우선, 가장 먼저 필요한 작업은 Microsoft Data Access Application Block 프로젝트를 열어서 이 녀석을 컴파일 및 빌드하는 것입니다. 여러분의 시스템에 맞는 DLL로 빌드한 다음에 사용하는 것이 여러모로 유리하니까요 ^^ 이를 위해서는 먼저 위의 그림에서 보이는 것처럼 메뉴 중에서 Data Access Application Block을 실행하도록 하세요. 그러면, VS.NET이 열리면서... 해당 프로젝트가 로드될 것입니다.
프로젝트에는 달랑 SqlHelper.cs 클래스 하나만 존재하는 것이 보이는데요. 썰렁하다고 속상해 하실 거 없습니다. 이 클래스의 코드를 한번 살펴보세요. 그 길이가 만만치 않을 겁니다... 그리고, 바로 이것이 Microsoft Data Access Application Block 의 실체이기도 하지요 ^^;; 자. 소스를 한번 분석해 보고싶으신 분은 꼭 그렇게 하시구요.(단, 이를 위해서는 ADO.NET에 대한 내공이 필요할 것입니다) 우리는 일단 이 프로젝트를 빌드해 보도록 하겠습니다. 자. 어서들~~ 모두모두 빌드(Ctrl+Shift+B) 해주세여~~~~ ^^; 그러면, Microsoft.ApplicationBlocks.Data.dll 파일이 만들어지게 될 것입니다. 그리고, 그렇게 만들어진 DLL 파일은 다음과 같은 경로에 존재하게 되지요 ^^ 설치 디렉터리 :\Program Files\Microsoft Application Blocks for .NET\Data Access v2\Code\CS\Microsoft.ApplicationBlocks.Data\bin\Debug 다음 그림과 같이 말입니다. ^^
하하.. 이제 DLL도 준비가 되었으니, 한번 예제를 진행해 볼까요? 새로운 ASP.NET 웹 어플리케이션 프로젝트를 하나 만드세요(물론, Microsoft Data Access Application Block은 웹 어플리케이션 뿐만 아니라 윈도우즈 어플리케이션에서도 사용이 가능합니다. 어디서나 사용할 수 있지요). 저는 DataAppBlock란 이름으로 웹 프로젝트를 하나 만들었습니다. 그러면, 기본적으로 프로젝트와 함께 생성된 WebForm1.aspx라는 파일이 존재하지요? 우리는 간단하게 이 파일에 DataGrid를 하나 올리고, Microsoft Data Access Application Block을 사용해서 데이터베이스로부터 데이터를 가져와서 이 그리드 컨트롤에 바인드하는 간단 예제를 진행해 보도록 하겠습니다. 그렇다면, 일단, 웹 폼에 DataGrid 컨트롤을 하나 올려야 하겠죠? 네.. 그렇게 해주시구요. 그 그리드를 선택하시고 마우스 우측 클릭하여, [자동 서식] 메뉴에서 [단순 3]을 선택해 보도록 하겠습니다. 뭐.. 사실 이러한 서식은 원하시는 무엇을 선택하던 무관하지만요 ^^ 다 되셨으면, 이제 코드 비하인드 페이지로 이동합니다. 그리고, 참조 폴더에 마우스 우측 클릭하여 그 DLL에 대한 참조를 설정하도록 합니다. 즉, 아까 빌드해 놓은 Microsoft.ApplicationBlocks.Data.dll을 참조하시면 된다는 것이지요 ^^ 그러면, 다음과 같이 Microsoft.ApplicationBlocks.Data가 참조될 것입니다. 멋지죠???
이제, 코드 비하인드 페이지에서 이 DLL을 편하게 사용하기 위해서 네임스페이스를 임포트 해보도록 해요. 클래스의 상단에 다음과 같이 한줄의 코드를 추가하시면 되겠죠?
넹. 그렇습니다. 그렇다면, 이제 실제 데이터베이스에서 데이터를 가져와서 바인드 하는 코드를 작성해 볼까요? 다음과 같이 Page_Load 구역을 작성해 주시면 되겠습니다.
하하... 좋았습니다. 아주 간단하죠? SqlHelper 클래스의 ExecuteReader 메서드는 수많은 오버로드들을 가지고 있는데요. 공통적인 것은 ExecuteReader라는 메서드가 언제나 SqlDataReader 클래스를 반환한다는 것입니다. ^^;; 이는 SqlCommand 클래스의 경우와 동일하죠! 저의 경우는 SqlHelper 클래스의 ExecuteReader 메서드 중.. 첫번째 인자로 데이터베이스 연결 문자열을 사용하고, 두 번째 인자로 명령타입을 사용하고, 세번째 인자로는 명령문자열을 사용하는 오버로드 버전을 사용해 보았습니다. 이를 사용하면, SqlHelper 클래스가 내부적으로 첫번째 인자인 연결 문자열을 가지고 SqlConnection 개체를 생성하여 연결을 시도하게 된답니다. ^^ 자. 코드를 모두 작성하였다면, 이제 한번 WebForm1.aspx 페이지를 실행해 보세요 ^^;; 아마도 멋드러지게 실행되어 다음과 같은 결과가 나올 것임에 틀림이 없습니다.
오홋홋.. 멋지지 않나요???? 이렇게 사용하는 것이랍니다. 간단하죠??? 사용하는 것은 간단합니다만, 내부는 그렇게 간단하지 않습니다. 하지만 그렇다고, 아주 복잡하지도 않습니다. 여러분이 ADO.NET에 익숙한 편이고, 도전할 마음자세가 되어있다면, 한번 소스 분석에 도전해 보시는 것도 좋습니다. 힘든 과정일 수도 있겠지만 자신의 발전에 큰 도움이 될 테니까요. 그렇게 말하는 태오는 해 보았냐구요??? 음... 참으로 .... 의심이 많으신 분들이시구만요.. 음... 음... 대답을 꼭 해야 하나요???? 제가 질문하고 제가 답변하는 게 우습기도 하지요? ㅋㅋㅋ 해서, 대답 안하겠습니다. 알아서 상상해 주셔요~~~~ ㅋㅋㅋ 이제, 아주 간단한 예제를 하나 해 보았는데요. 이는 Microsoft Data Access Application Block의 맛을 본 수준에 불과합니다. 이 친구는 이러한 간단한 예제뿐만 아니라, 트랜잭션을 사용하는 조금 복잡한 처리도 처리할 수 있는 능력을 가지고 있기에... 상당히 기능이 방대한 편이니까요. 여러분이 Microsoft Data Access Application Block을 더욱 더 잘 알고자 하신다면, 이 녀석을 자주 사용해 보아야만 합니다. 그래야만 "아... 이럴 때 이녀석을 사용하면 좋겠구나" 라는 감을 잡으실 수 있으니까요. 사용하는 방법도 대충 감 잡으셨으니... 이번 기회에 이 녀석을 한번 애용해 보세요... 재미도 있을 것이고, 뭔가 코드가 고급스러워 보이기에 기분도 좋아질 것 입니다. 하하하.. 하지만, 이 친구를 지금!! 실무에 적용하려고 한다면 잠시 제 이야기를 좀만 더 들어봐 주십시요. 분명, 이 Microsoft Data Access Application Block이 멋진 친구이기는 합니다만 말입니다. 좋은 녀석이라고 아무때나 마구 사용하려는 자세는 그다지 바람직하지 않습니다. 규모가 작은 어플리케이션에서는 오히려 Microsoft Data Access Application Block을 사용할 경우, 성능적으로 좋지 못할 수도 있으니까요. 데이터 처리 과정을 상당 부분 추상화 시켜놓은 것이 Microsoft Data Access Application Block이기에 말입니다. 그렇기에, 이 블록을 사용하는 것은 여러분이 ADO.NET으로 코드를 작성한 경우보다 하나의 쿼리 명령을 수행하기 위해서 더 복잡한 처리를 거쳐서 명령이 수행될 가능성이 매우 큽니다. 아니 거의 그렇습니다. 그렇기에, 이는 효과적이긴 하지만 성능적으로는 조금 성능이 떨어질 수도 있다는 것입니다. 하지만, 성능이 어플리케이션의 전부는 아닐 것입니다. 안정성, 확장성, 유지보수성등도 사실 웹 어플리케이션의 중요한 요소이지요. 바로, Microsoft Data Access Application Block는 그러한 측면에서 상당히 유리한 환경을 제공해 주기에 이렇듯 제가 추천드리고 있는 것입니다. ADO.NET에 익숙한 개발자가 아니라면 여러분이 직접 작성한 코드는 오히려 불안요소(!)가 될 수도 있을테니 말입니다. 물론, 선택의 여러분의 몫입니다. 개발자라면 일단 공부해 두는 것이 확실히 유리합니다. 하지만, 실무에 적용할 생각이라면 먼저 이 친구와 상당히 친해져야 할 것입니다. 그러면, 이 친구를 어떻게 적용해야 프로젝트에 효과적일지, 어떤 프로젝트에 이 친구를 적용해야 할지 등이 보이기 시작할 것입니다. 사실, Microsoft Data Access Application Block는 윈도우즈 프레임워크의 다중계층 모델에서의 Data 처리 계층을 지원하고자 준비된 것입니다. 즉, 이는 일종의 데이터 추상화 블럭이라는 의미이지요. 해서, 직접적으로 이를 웹 어플리케이션에서 불러 사용하는 것은 그다지 좋은 방법이 아닙니다. 이 기술은 가급적 별도로 구성된 데이터 계층쪽 컴포넌트에서 사용하는 것이 효과적이라는 것이죠. 말이 뭔가 개념적인데요.... 음.. 좋습니다. 이 부분의 이야기를 약간 덧붙여 보겠습니다.... 여러분이 조금은 웹 어플리케이션 제작에 경험이 있으신 개발자라면 말입니다. 규모가 조금 있는 웹 어플리케이션의 경우, 대부분 다음과 같은 논리적인 구성을 가지게 된다는 것을 여러 세미나나, 중급용 서적 등에서 많이들 들어보셨을 것입니다.
즉, 3 Tier 식의 구성을 말입니다. 사실, 모든 웹 어플리케이션이 이렇게 구성되어야 하는 것은 아닙니다. 논리적으로 티어(계층)을 나누느냐, 나누지 않느냐의 결정은 사이트의 규모와 스펙, 그리고 개발 기간 및 비용들이 고려되어져서 결정되어야 할 부분일테니까요. 참고로, 태오 사이트도 현재까지는 3 티어로 구현되어져 있지 않습니다. 현재 준비중인 .NET 버전에서는 이러한 논리적인 계층을 적용하고 있긴 합니다면, 사실 반드시 그래야하는 것은 아님에도 불구하고, 개인적인 욕심에 도전해 보고 있답니다... 그렇게 하는 것이 확장성과 관리 측면에서 조금은 낫지 않을까 합니다만.. 성능면에서는 오히려 약간 떨어지지 않을까 싶기도 합니다. 하지만, 삼정 데이터서비스(태오 사이트를 호스팅해주는 업체)에서 제공해 주는 서버가 워낙 짱짱한 친구인지라.. 부담없이 한번 시도하고 있는 것이기도 하지요 ^^ 어쨋든 쓰리티어 식의 구성은 위와 같이 논리적으로 데이터 처리 계층과 비즈니스 처리(즉, 업무처리) 계층, 그리고 그것을 표현하는 표현 계층으로 구성되는 것이 일반적입니다. 그럼 각각의 계층은 어떠한 역할을 일반적으로 수행할까요? 간단하게만 알아볼까요??? 일단, 대부분 데이터베이스와의 쿼리 작업은 데이터 처리 계층에서 수행됩니다. 데이터 처리 계층(Data Layer)은 그러한 처리에 의해 반환되는 결과(레코드셋 혹은 단일 값, 혹은 DataSet 등)를 비즈니스 계층에게로 반환하는 역할을 하곤 하지요~. 즉, 데이터베이스 관련된 모든 코드는 이 계층(레이어)안에 들어있다고 보아도 무방합니다. 두 번째 계층인 비즈니스 계층(Business Layer)은 데이터 처리 계층이 반환한 값을 가지고 추가적인 가공이 필요할 경우, 가공을 하는 등의 작업을 하여 표현 계층에게 넘겨주는 역할을 주로 담당합니다. 그리고, 사용자가 직접적으로 마주하게 되는 마지막 계층인 표현 계층(Presentation Layer)은 그러한 최종 데이터를 받아서 적절한 형태로 출력해주는 역할을 담당하는 것이지요. 그리드(표)로 출력한다든지, ActiveX 컨트롤로써 출력한다던지, DHTML을 사용해서 동적으로 화면을 나타낸다든지 하는 역할을 말입니다. 물론, 이러한 룰이 일반적이기는 합니다만, 사실 언제나 그런 것은 아닙니다. 상황에 따라서는 비즈니스 계층과 표현 계층을 하나의 계층으로 구현하기도 합니다. 쉽게 말해서, 2 Tier로 구현될 수도 있다는 것이지요. 사실, 기존의 ASP 어플리케이션은 주로 이러한 형태를 띄곤 했었습지요. (아... 그렇습니다. 사실은, 컴포넌트를 사용하지 않은 대부분의 ASP 어플리케이션들은 위의 3 Tier를 모두 합친 형태이곤 했죠. 즉, 2Tier도 아닌, 계층이라는 말 자체가 필요없던 단일 계층의 구성으로 말입니다. ^^;; 태오 사이트도 그랬고, 수많은 웹 사이트들이 사실 그러했었죠. 그래서, Security Hole이 터지거나 보안적인 문제가 터지면, 상당히 취약했었던 것이 사실입니다. 하하하.. -_-++) 논리적으로 계층을 나누고, 그에 맞게 어플리케이션을 구성하기 위해서는 개발자는 적어도 하나 이상의 프로그래밍 언어(ASP는 언어가 아닌 스크립트 기반 플랫폼입니다)를 알고 있어야 합니다. 컴포넌트는 스크립트로 만들기 어렵기 때문이지요. 가장 많이 사용되었던 언어는 역시나 Visual Basic 이었습니다. 이는 .NET이 어느정도 자리를 잡은 지금까지도 계속되고 있기도 합니다.. 하하 여기까지의 이야기를 들은 몇몇 개발자분들은 마치 이렇게 쓰리티어로 구현하는 것이 중급적인 설계이며 기획이라고 생각하실 지도 모르겠는데요. 그게 반드시 그런 것은 사실 아니랍니다. 이러한 다중 티어의 구성이 언제나 훌륭한 것은 아니라는 점도 기억하세요. 이러한 구현이 여러 측면에서 훌륭할런지는 모르겠지만, 규모가 그리 크지 않은 사이트에서 이러한 구성을 구현하는 것은 일단 개발기간 및 비용에서 상당한 부담이 들 것이며, 유지 보수도 그리 좋지 않을 것이고, 또한 성능도 그다지 좋지 않을 수 있습니다. 이러한 다중 티어는 상당한 규모를 가지고 있어서 논리적인 계층의 분리로 인한 성능의 감소가 크게 이슈가 되지 않는 규모있는 사이트에 적합하다 할 수 있겠습니다. 고작, 게시판 3-4개와 정적 컨텐츠를 보유한 사이트.. 동시 사용자가 몇 명도 되지 않는 사이트에서라면.. 굳이 이렇게까지 복잡하게 구성하실 필요는 없을 것이라 생각합니다.(이는 개인적인 사견임을 밝힙니다) 만일, 그렇게 작은 사이트임에도 불구하고 위와 같은 구성을 고집하신다면 그것은 개발자의 열정으로 인한 것이겠지요 ^^; (사실, 제가 그렇습니다.) 말이 다른 곳으로 많이 샜는데요. 다시 원래로 돌아가서 Microsoft Data Access Application Block이라는 것에 대해서 이야기를 하자면요. 이 친구를 적용할 경우, 여러분은 기존의 계층 구성을 다음과 같이 구성할 수 있게 된다는 것입니다.(그림만으로는 머리에 쉽게 이해가 안될 것도 같네요 -_-;)
하지만, 실제 상황에서는 위의 그림처럼 그런 식으로 광범위하게 Microsoft Data Access Application Block을 사용하지는 않습니다. Microsoft Data Access Application Block는 오직 Data Layer쪽에서만 사용하지요. Data Layer에서 해야할 부분을 일부 추상화, 블럭화 해 놓은 것이 바로 Microsoft Data Access Application Block이기 때문입니다. 간혹, 규모가 작은 사이트의 경우는 Microsoft Data Access Application Block을 웹 말단, 즉, Presentation 계층에서 직접 불러다가 사용하곤 하기도 합니다만, 그것은 그다지 추천되지 않는 편입니다(물론, 그렇게 해서는 안된다는 것은 아닙니다). 강조하지만, Microsoft Data Access Application Block는 어느정도 규모가 있는 사이트에 적용할 경우 유리합니다. 또한, 논리적으로 데이터 처리 계층이 구분지어져 있는 경우 그 사용은 더욱 효과적일 것입니다. 그 기준이 조금 모호하기는 말입니다.... -_-;;;;; 그렇다면, 도대체 태오는 왜 Microsoft Data Access Application Block을 이토록 강조하고 있는 것일까요? 바로, 다음 시간부터 진행할 계층형 게시판의 3-Tier 버전에 바로 Microsoft Data Access Application Block를 사용하려 하기 때문입니다. 또한, 현재 제작중에 있는 태오 사이트 .NET 버전에서도 Microsoft Data Access Application Block를 적용하고 있기 때문이기도 합니다. 그렇기에 여러분들은 이 친구를 조금쯤은 알아야 한다는 것입니다. 알아두면 피가 되고 살이 되는 녀석인데다가, SqlHelper 클래스의 구조를 살펴볼 경우, 클래스 설계를 어떤 식으로 해야하는지, 설계를 어떻게 하는 것이 바람직한 것인지 힌트를 많이 많이 얻을 수 있을테니까요. 그렇다면, 이제 한번 천천히 이 친구를 만지작(!!)거려 보세요. 의외로 재미있는 구석이 많을 겁니다. 그러는 동안, 저는 다음 강좌 즉, 게시판을 모델로 하여 다중 계층으로 구성하는 .NET 구현에 대한 글을 준비해 보도록 하겠습니다. 왠지, ...... 뭔가 이번 강좌는 정신없고, 조잡스러운 감이 없지 않았나 싶네요. 죄송합니다... 워낙 방대한 기술을 요약해서 설명하려니 그렇게 된게 아닌가 싶습니다. 이 점 여러분의 많은 양해가 있으시기를... 헤헤헤~~~~ 감사합니다. 좋은 하루 되세요~~~
|
