스팅의 불(火)로그

출처 : http://blog.tobegin.net/39  / Writer by 정은성

IBM 사이트에서 번역된 JQuery 강좌입니다.

간단하지만 보면 도움이 될거 같습니다.

jQuery로 작업하기, Part 1: 브라우저로 데스크톱 응용 옮기기

jQuery로 작업하기, Part 2: 내일 나올 웹 응용을 오늘 구현해보자

jQuery로 작업하기, 3부: jQuery와 Ajax로 RIA 만들기

jQuery로 작업하기, Part 1: 매개체로서의 JQuery: 플러그인을 사용하여 jQuery 함수를 작성하고 확장하기 

jQuery로 작업하기, Part 2: 매개체로서의 JQuery: UI 프로젝트 

jQuery로 작업하기, Part 3: 매개체로서의 JQuery: 고유한 플러그인 작성하기 

Ajax로 사이트 전면 개편, Part 1: Ajax와 jQuery로 기존 사이트 개선하기 

Ajax로 사이트 전면 개편, Part 2: jQuery, Ajax, 툴팁, 라이트박스로 기존 사이트 개선하기 

Ajax로 사이트 전면 개편, Part 3: jQuery, Ajax 탭, 회전식 슬라이드쇼로 기존 사이트 개선하기 

Ajax로 사이트 전면 개편, Part 4: 기존 사이트를 jQuery와 Ajax forms를 사용하여 개선하기 

JSONP를 사용한 도메인 간 통신, Part 1: JSONP와 jQuery의 결합으로 강력한 매시업 빠르게 만들기 

JSONP를 사용한 도메인 간 통신, Part 2: JSONP, jQuery 및 Yahoo! Query Language로 매시업 만들기 

Scala, Lift 및 jQuery를 사용하여 Comet 애플리케이션 빌드하기 

매개체로서의 jQuery(1) 

매개체로서의 jQuery(2) 

고급 jQuery(1) 

고급 jQuery(2) 

jQuery로 Ajax 개발을 단순화 하기 
[출처] IBM jQuery 라이브러리 강좌 URL|작성자 끝판대왕

ASP.NET의 주요 명령어 정리 : 내장 개체

▶ Response개체 : 응답(서버(C#)에서 클라이언트(IE)로)
     .Write() : 페이지에 문자열 출력
     .Redirect() : 해당 페이지로 이동
     .Expires : 현재 페이지의 새로 고침 기능
          Response.Expires = -1; // 응답캐시 지우기
     .Buffer : 버퍼링 사용 설정
          Response.Buffer = true; // 버퍼링
     .Flush() : 현재 버퍼 내용 출력
     .Clear() : 현재 버퍼의 내용 비우기
     .End() : 현재 페이지 종료...
     .WriteFile() : 파일 출력
     .Cookies[] : 쿠키 저장
     
▶ Request개체
     .QueryString[] : 넘겨져 온 쿼리스트링값을 반환 : key/value쌍으로…
          Get방식 : URI(URL)에 ? 뒤에 키와 값으로 전달
     .Form[] : Post방식으로 넘겨져 온 값 반환
          Post방식 : HTTP 헤더에 데이터를 실어서 전송
     .Params[] : Get/Post 방식 중 아무거나 다 받음.
     Request[] : Params[] 컬렉션과 동일
     
     .UserHostAddress : IP주소
     .ServerVariables["REMOTE_HOST"] : IP주소
     .ServerVariables["REMOTE_ADDR"] : IP주소
     
     .Cookies[] : 저장된 쿠키 읽어오기.
     
▶ Server개체
     .MapPath(".") : 현재 파일과 같은 경로 값 반환 : .., /, \
     .Execute() : 다른 파일 포함(인클루드)후 제어권 돌아옴
     .Transfer() : 다른 파일 포함(인클루드)후 제어권 넘김 : Execute() + Response.End()
     .UrlPathEncode() : 넘겨져온 쿼리 스트링을 유니코드로 변환(한글 처리)
     .ScriptTimeout : 서버측에서 현재 ASPX페이지를 몇초간 처리할 건지 설정
          대용량 파일 업로드 페이지는 일시적으로 Server.ScriptTimeout을 증가
          
▶ Application개체
     - Application 전역 변수 선언(Public)
          Application["변수명"] = 값; // 딱 한개만 생성
     .Lock() : 애플리케이션 변수를 잠그는 메서드
     .UnLock() : 잠긴 애플리케이션 변수를 해제하는 메서드
     
▶ Session개체
     - Session 전역 변수 선언(Private)
          Session["변수명"] = 값; // 사용자 수 만큼 생성
     .Abandon() : 현재 세션 지우기
          예전에는 세션으로 로그인 처리시 로그아웃 할 때 사용
     .SessionID : 현재 세션의 고유번호 값 반환
          GUID와 비슷 : 한명이 접속하면 웹서버는 고유한 인증값을 부여
     .SessionTimeout : 세션 시간 기록 : 기본값 20분... 더 추가시키거나 줄일경우 사용...
     
▶ Page 개체
     .IsPostBack : 현재 페이지가 처음 로드했는지, 다시 게시(PostBack)되었는 지 확인
          처음로드 : Page.IsPostBack => false
          다시게시(PostBack) : Page.IsPostBack => true
     .RegisterClientScriptBlock() : 자바스크립트를 동적으로 웹 페이지에 추가
          Page.ClientScript.RegisterClientScriptBlock(this.GetType(), "스크립트 구분 이름", "자바스크립트코드");
     .RegisterStartupScript() : 자바스크립트를 동적으로 웹 페이지에 추가
          Page.ClientScript.RegisterStartupScript(this.GetType(), "스크립트 구분 이름", "자바스크립트코드");
     
▶ System.Web.Security.FormsAuthentication 개체 : 인증 관련
     
     [1] .SetAuthCookie() : 인증 쿠키값 부여... 인증 처리
          .GetRedirectUrl() : 인증 받기 이전의 페이지 경로값 반환.
     [2] .RedirectFromLoginPage() : 인증 처리와 동시에 이전(인증 받기 전) 페이지로 이동
     [3] Page.User.Identity.Name : 인증된 사용자명, SetAuthCookie()에서 부여된 인증 쿠키값, Admin, RedPlus식
     [4] Page.User.Identity.IsAuthenticated : 인증(로그인처리)되었다면, true, 그렇지 않으면 false를 반환
     
▶ 상태관리
     서버에 저장 : 웹 애플리케이션 전체에서 살아있는 변수값 저장
          Application[] : 1개만
          Session[] : 여러개
          Cache[] : 1개만 빠른 메모리에 저장
     클라이언트에 저장
          ViewState[] : 웹 브라우저의 소스코드에 히든필드로 저장
          Response.Cookies[] : 웹 브라우저에 쿠키 저장
          Request.Cookies[] : 저장된 쿠키 읽어오기

▶ 캐싱
     <%@ OutputCache Duration="3600" VaryByParam="None" %>
          3600초 동안 현재 페이지를 캐싱(메모리에 처리 결과 담고 바로 출력)

Request URL: http://WebResource.axd?d=9n4PyABCLnJPx4xoU3nxwC4Kt15K3u-a245UfT6hW8JSf4r6suGuS1kEScfmyvro0&t=633739595980000000

로컬테스트 및 개발서버에서 정상적으로 되던것들이 리얼서버로 올라갔을때 위메세지 처럼 발생하는 에러를 가끔씩 보실 수 있습니다.

WebResource.axd 는 ASP.NET 2.0에서 기본적으로 제공하는 HttpHandler 로서 커스텀 컨트롤의 DLL 내에 embedded resource 로서 제공되는 .gif .js .htm 등을 반환하기 위해 추가된 기능입니다.
WebResource.axd 가 리소스가 포함된 DLL과 리소스의 ID를 query string에 포함시키고 이것을 암호화 하는데 디폴트 암호화 알고리즘이 (AES)Rijndael 알고리즘 입니다.

이 알고리즘은 ASP.NET의 기본설정은 암호화/복호화에 사용하는 키를 자동생성 합니다.
암호화 할 때 사용한 키와 복호화 할 때 키값이 다를경우 예외가 발생합니다.

예외가 발생될 경우

/WebResource.axd?d= .... 렌더링 할 때 사용한 (자동 생성된) 암호화 키와 실제 이 URL이 요청되었을 때의 (자동 생성된) 복호화 키가 다를경우 패딩예외가 발생하는 것입니다.

ASP.NET으로 구성된 웹 어플리케이션 서버가 L4 Switch에 의하여 Load Balancing 되는 경우..

- 웹 페이지 접속 시 ASP.NET 컨트롤에서 없던 오류날 경우

- 이미지가 액박 표시 되는 현상

이 경우 Fiddler를 통하여 페이지 요청 시 WebResource.axd 요청이 실패하는지 확인합니다.
해당 요청에서 문제가 있다면 서버의 이벤트 로그에는 다음과 같이 CryptographicException 오류가 발생하였는지 확인해보는 것이 좋습니다.

Event code: 3005
Event message: 처리되지 않은 예외가 발생했습니다.
Event time: 2010-07-26 오후 오후 1:05:45
Event time (UTC): 2010-07-26 오후 1:05:45
Event ID: 28188a45397841e499de7a4c38b4f4cd
Event sequence: 61
Event occurrence: 3
Event detail code: 0
 
Exception information:
    Exception type: CryptographicException
    Exception message: 패딩이 잘못되었으며 제거할 수 없습니다.
 
Request information:
    Request URL: http://WebResource.axd?d=9n4PyABCLnJPx4xoU3nxwC4Kt15K3u-a245UfT6hW8JSf4r6suGuS1kEScfmyvro0&t=633739595980000000
    Request path: /WebResource.axd

[패딩이 잘못되었으며 제거할 수 없습니다. (Padding is invalid and cannot be removed.)]

이 에러는 WebResource.axd 파일을 요청할 때 발생합니다.
이 파일은 ASP.NET의 컨트롤을 사용하는 경우 요청되는데요.
이 때 암호화 작업이 발생합니다. 암호화에 사용되는 Machine Key는 서버가 가지고 있습니다.
ASP.NET에서 Machine Key를 설정한적이 없다면 동적으로 생성되어 사용됩니다.

서버가 한대일 경우는 상관 없지만, 여러대 이면서 LoadBalancing을 하는 경우는 문제가 발생합니다. 요청마다 서버가 바뀌므로 암호화 키를 전달해준 서버가 아닌 서버가 암호화된 정보를 받는다면 해독할 수 없으므로, 위 처럼 오류가 발생하는 것이지요.

이는 모든 웹 어플리케이션 서버의 Machine Key를 동일하게 함으로 해결할 수 있습니다.
새로운 Machine Key 키 생성은 다음의 사이트에서 도움을 받으세요.

http://aspnetresources.com/tools/machineKey

생성된 Machine Key는 web.config에 다음의 형태로 삽입하면 됩니다.
 </system.web>
 <machineKey validationKey="D3373ECBFB7F1D94A57890DD8C676F5E925713E79BCF5A8A2692D408A5E9A1E06ED9FBF352B876D2B465EE70DDCF69CA2FD263711401ED6171ED5AC8F795E88A" decryptionKey="0B12BC1D697005FF915095556F3E528F261F5D08847AAB9881E409D525D1D5C6" validation="SHA1" decryption="Auto" />
 </system.web>

참고자료
-- machineKey 요소(ASP.NET 설정 스키마)
http://msdn.microsoft.com/ko-kr/library/w8h3skw9.aspx

출처 : http://inaekkuya.blog.me/70090690083

Visual SourceSafe over the Internet using HTTP

여러 명이 공동작업을 하는 데 프리랜서 그룹이라고 하자. 멋있는 말로 분산개발환경이라고 하면 되나? 이번에 나온 Visual SourceSafe(VSS, 소스세이프)는 인터넷을 통한 작업이 가능하게 지원을 한다. SSL을 이용하면 더 안전하겠지만 이 부분은 생략하기로 한다.
먼저 Visual SourceSafe를 설치하고 공유할 데이터 베이스를 지정한다. HTTP를 사용할 경우 로컬인 경우도 꼭 \\ComputerName\SharedFolderName 으로 지정을 해야한다.


새로 추가된 기능의 하나로 Multiple Checkouts를 지원한다.


보안에 대한 안내로 Everyone 그룹에 대한 권한이 있다면 제거하라는...



HTTP를 통한 소스세이프 사용을 위해 SSL을 사용할 것을 권한다. 현재는 테스트라 Yes를 눌러 무시했다.

IIS관리자에 해당 SourceSafe 가상 폴더가 생성되고 VssService.asmx 웹서비스가 구성된 것을 확인 할 수 있다.

ASP.NET 1.0을 동시에 쓰는 경우는 꼭 APP Pool을 ASP.NET 2.0으로 맞춰주길~


WebDAV가 허용되어 있는 것을 확인할 수 있다.

Visual Studio 2005의 Tools ? Option을 보면 아래와 같이 Internet을 통한 소스제어가 가능하게 선택을 할 수 있다.

설정을 변경하고 프로젝트를 오픈하면 그림과 같이 SourceSafe (Internet)항목이 보인다.

Address에는 http경로를 넣으면 된다. 예를 들면 http://aaa.bbb.com/ 그리고 Folder에는 \\ComputerName\SharedFolderName ....

동석이의 블로그 | 허둥사마
http://blog.naver.com/tit99hds/120018010240

개요

페이지의 실행주기가 언뜻 아무것도 아닌것처럼 보이나 어떠한 복잡한 로직이 페이지에 구현될때

실행주기때문에 머리가 엉킨 경험을 한번씩은 경험 해 보았을 것이라고 생각합니다.

페이지의 실행주기를 한번만 확실히 집고 넘어가면 앞으로 개발하는데 많은 장점이 있을 듯 합니다.

<%@ Page Language="C#" Debug=true %>

<Script Language="C#" Runat="Server">

string s = "데이타 바인드 하기";

private void Page_Init(Object o , EventArgs e)




{




 Response.Write("Page_Init 이벤트 발생!<p>");




}

private void Page_Load(Object o , EventArgs e)




{




 Response.Write("Page_Load 이벤트 발생!<p>");




}

private void Page_PreRender(Object o , EventArgs e)




{




 Response.Write("Page_PreRender 이벤트 발생!<p>");




}

private void Page_Unload(Object o , EventArgs e)




{




 //페이지가 메모리에서 언로드 될때 발생, 아직 해제(disposed)되지는 않는다




 //응답을 사용할수 없다(Respnose개체 사용 불가)




 //화면에 출력하는 코드를 사용할 수 없다




}

private void Page_Disposed(Object o , EventArgs e)




{




 //페이지 생명주기 마지막 단계




 //페이지가 메모리에서 해제됨




}

private void DoClick(Object o , EventArgs e)




{




 Response.Write("클릭 이벤트 발생!(포스트 백 일어남)<p>");




 //Page.DataBind();




}




</Script>

<form runat="server">




 <asp:Button Runat="Server" OnClick="DoClick" Text="클릭!" /><p> <%# s %>




</form> 

위의 코드는 페이지 실행주기동안에 발생하는 대부분의 이벤트입니다.

1. 페이지가 처음 로딩될 경우 [ init -> load -> PostBack체크 -> preRender 순으로 발생 ]

2. 포스트 백(버턴클릭시)이 될 경우 [ init -> load -> PostBack체크 -> 버턴클릭이벤트 -> PreRenader 순으로 발생 ]

주의 할 것은 포스트백이 일어날때 Page_Load 이벤트는 다시 호출되며 컨트롤의 

이벤트보다 먼저 수행된다는 점입니다. 

실수를 해보지 않은 사람은 다 아는 내용이지 않는냐 하겠지만 한번씩 실수를 해본 사람은 

이미 알고 있고 또한 기본적이지만 중요한 개념입니다. 

그리고 Page_PreRender 이벤트는 컨트롤의 이벤트 뒤에 또는 처음로딩시 호출되기에 

나름대로 유용하게 쓰일 수 있는 이벤트이기도 하죠. 

Page의 또다른 이벤트인 DataBind 입니다. 

이 놈은 페이지에서 DataBind 가 호출될때 발생하는 이벤트 입니다. ( ex> Page.DataBind(); ) 

이 외에도 실행주기에 대한 내용은 많지만 제가 아는 내용은 대략 이정도군요^^ 

<<정규화(Normalization)>>

* 함수의 종속성(Functional Dependency)
- 데이터들이 어떤 기준값에 의해 종속되는 현상을 지칭

- 결정자(determinent) --> 종속자(dependent)

  ex> 주민등록번호 --> (이름, 출생지, 주소)

1. 제1 정규화
- 복수의 속성값을 갖는 속성의 분리
- 즉, 테이블 하나의 컬럼에는 여러 개의 데이터 값이 중복되어 나타나지 않아야 한다.

- 모든 엔티티 타입의 속성에는 하나의 속성 값만을 가지고 있어야 하며 반복되는 속성 값의 집단은 별도의 엔티티 타입으로 분리한다.

- 로우(Row) 단위로 1차 정규화가 안된 모델은 PK의 유일성이 확보되지 않으므로 인해 실전 프로젝트에서는 거의 찾아보기 힘들다.

- 반면 로우 단위로 중복된 내용을 컬럼 단이로 펼쳐 중복하는 경우가 아주 많이 발견되는데 추가 업무 발생시 모델을 변경해야 하는 치명적인 결함이 있다.

2. 제2 정규화
- 주식별자에 종속적이지 않은 속성 분리
- 주식별자를 구성하는 일부 속성에 종속적인 속성(부분 종속 속성)을 분리하는 것.
- 주식별자가 둘 이상의 컬럼으로 이루어져 있을때 모두에게 종속적이어야 한다.

- 반드시 자신의 테이블을 주식별자를 구성하는 속성이 복합 식별자일 경우에만 대상이 되고 단일 식별자일 경우에는 2차 정규화 대상이 아니다.

- 코드 유형의 엔티티 타입들이 2차 정규화가 되지 않고 하나의 엔티티 타입으로 표현되는 경우가 많다.

3. 제3 정규화
- 주식별자가 아닌 속성에 종속적인 속성 분리.
- 주식별자에 의해 종속적인 속성 중에서 다시 속성 간에 종속관계(이전 종속)가 발생되는 경우

- 결정자 역할을 하는 일반 속성이 존재하고, 결정자 역할 속성에 의존하는 의존자가 존재하는 엔티티 타입이 대상이다.

4. 보이스-코드 정규화(BCNF)
- 테이블에 존재하는 식별자가 여러개 존재할 경우 식별자가 중복되어 나타나는 현상을 제거

- 주식별자 속성 중에 주식별자의 유일성을 확보하는 최소한의 속성이 아닌 쓸데없이 추가된 속성을 분리하는 것.

5. 제 4정규화
- 특정 속성값에 따라 선택적인 속성의 분리

- 하나의 테이블에 두 개 이상의 독립적인 다가속성(multi-valued attribute)이 존재하는 경우에 다가종속(multi-valued dependency)이 발생되어 문제가 생긴다. 다가종속이란 하나의 속성 값에 두개 이상의 의미를 가지는 값을 가지는 것을 의미한다.

- 실제로 2정규화나 BCNF보다 더 많이 발생된다.

- 불필요한 관계때문에 새로운 값을 채울 경우에 값을 기본값(Default value)으로 지정해버리는 경우가 많이 있다. 참조무결성(FK)를 걸지 않는 경우에 가능한데 좋지 않은 경우이며 이와 같은 경우 데이터모델에 나타난 관계가 실제 데이터에서 불가피하게 단절되어 나타나므로 무결성 체크가 불가능해진다.

원래 정규화란 중복성을 최소화하고 정보의 일관성을 보장하기 위한 관계형 데이터 베이스에서 제일 중요한 개념인데요

제1정규화는  < repeating group 제거>

여러 값을 가진 컬럼이 존재할 수 없다. 즉 반복되는 그룹이 존재해서는 안 된다. 각 행과 열에는 하나의 값만이 올수 있다.
예를 들면

고객번호(P.K) 고객명 취미
1 노무현 영화
여행
2 이화숙 등산

이런 테이블이 있을수는 없고 이걸 수정한다면

고객번호(P.K) 고객명
1 노무현
2 이화숙

하고 또하나

고객번호(P.K) 일련번호(P.K) 취미
1 1 영화
1 2 여행
2 1 등산

이런식으로 두개로 분리해야 한다는거죠

제2정규화 < 부분종속 제거 >

모든키가 아닌 컬럼은 기본 키 전체에 의존적이여야 한다. 기본키의 일부분에 의존적이어서는 안 된다.

예를 들어

사번(p.k) 프로젝트번호(p.k) 부서 프로젝트역할 고과율
1 a 전산 팀장 A
1 b 전산 조원 C
1 c 전산 부팀장 B
2 c 경리 팀장 A
3 c 기획 팀장 A

이 테이블의 기본키는 사번과 프로젝트번혼데 부서 컬럼은 사번에만 의존적이다.
이것은 2정규화를 거치면

사번(p.k) 프로젝트번호(p.k) 프로젝트역할 고과율
1 a 팀장 A
1 b 조원 C
1 c 부팀장 B
2 c 팀장 A
3 c 팀장 A

요렇게 하고 부서 테이블을 다시 따로 때네서

사번 부서
1 전산
2 경리
3 기획

요렇게 해서 릴레이션을 걸면 됩니다.

그리고 3정규화 < 이행종속 제거 >

키가아닌 컬럼은, 다른 키가 아닌 컬럼에 의존적일어서는 안된다.
예를 들어

사번(p.k) 프로젝트번호(p.k) 프로젝트역할 고과율
1 a 팀장 A
1 b 조원 C
1 c 부팀장 B
2 c 팀장 A
3 c 팀장 A

요 테이블을 다시 보면 고과율은 프로젝트 역할에 의존적인걸 알수 있습니다.

이것을 또 3정규화 거치면

사번(p.k) 프로젝트번호(p.k) 프로젝트역할
1 a 팀장
1 b 조원
1 c 부팀장
2 c 팀장
3 c 팀장

프로젝트역할 고과율
팀장 A
조원 C
부팀장 B

요렇게 또 따로 때네줘야 합니다

제4정규화는
2정규화 된 테이블은 다대다 관계를 가질수 없다.

이건 따로 예를 안들어도 되겠죠?ㅋㅋ

authored by Lancers (안재우)

Interface 좀만 더 생각해보자.

개인적인 사견에 조금 과장을 곁들인다면 Interface가 OOP언어에서 가장 핵심적인 내용이 아닐까한다.

Interface의 이해정도에 따라 초급/중급 개발자로 나누어도 될듯하다.

특히나 J2EE쪽에서는 Interface를 알고있던 모르던 간에 필수적으로 사용되고 있다.

(당연히 알고 있을거라 생각합니다. 아 왠지 무시하는듯한 말투..그런 뜻 아닌거 아시죠..^^?)

J2EE기술중에 Interface를 쓰지않고 돌아가는것이 있을까?(본인의 얕은 지식으로는 없다고 생각합니다.)

/*

아이러니 하게도 필자는 C++ 프로젝트만 하고있는데도 설명은 자바로 하고 있네요..

뭔가 잘못된듯..솔직히 자바 잘 모릅니다..-.-;

Interface의 설명하는데 있어 역시 자바만한게 없다는 생각입니다.

Interface에 대해 논하기 가장 쉽습니다.(극히 개인적인 생각)

C++ 던 Java던 OOP언어에서 Interface의 이론은 대동소이합니다. 언어적으로 표현만 좀 다를뿐

*/

여기서 생각해 볼 것은 왜 껍데기 뿐인 Interface를 강조하는가!

필자가 공부할때(학교다닐때..아!! 벌써 약 10년전...-_-;), 당시엔 Java에서 Interface를 그리 중요하게 생각지 않았다.

물론 이러한 생각은 필자가 Interface를 제대로 이해하지 못했기 때문이었다.

"이런 껍데기를 왜 쓰는거지."

"왜 이런걸 써서 코드만 난잡하게..하는 거지.."

그러한 생각들로 인해..그리 중요하게 생각지 않고 넘어갔다.

그때는 단지 "음 언어적인 제약(반드시 구현해라)을 주기위해 그런것인 갑다"하고 넘어가곤했다.

(여러분은 어떤가요...? 저는 그랬습니다..^^)

Interface가 나온것은 여러 이유가 있겠지만...

여기서는 한가지 단면만을 토로하고자한다.

과거 C/S 기반에서는 클라이언트가 지금의 서버의 모든 기능을 가지고 있었다.

서버쪽은 단지 DB(주로...파워빌더가 그랬죠..? 아직도 많이 씁니다. 주로 사내용으로 사원관리, 급여관리 등등).

클라이언트가 직접 DB를 접속하였다.

이에 대한 문제점이 적지 않았는데..

일단 클라이언트가 모든 기능을 가지고 있는데서 문제가 있다라고 볼 수 있다.

1. DB의 접속 계정을 가지고 있다.

  => 보안에 취약.(이거 머 맘만 먹으면..-.-)

2. 모든 비지니스 로직을 가지고 있다.

  => 클라이언트의 비대화

  => 업데이트 비용이 많이 든다.

  => 비지니스 로직이 포함되어 있으므로 정책 변경에 유연하지 않다.

특히나 보안이나 정책 변경은 머리가 쥐가날 정도로 머리를 아프게 했다.

/*

정책 변경으로 인해 배포된 모든 클라이언트를 업데이트 해주자면..만만한 작업이 아니었습니다..

게다가 업데이트된 클라이언트, 아직 업데이트되지 않는 클라이언트를 모두 수용하자면..

생각만해도...머리가 지끈...

게다가 C/S가 유행하던 당시는 지금의 랜 환경과는 다르죠!!

*/

이러한 이유들로 인해

후에 나온 개념이 3-tier(지금은 환경이 다양해서 n-tier라는 말도 나오는데)라는것인데..

이 개념과 더불어 Thin Client라는 용어가 한때 유행하였다.

지금은 3-tier가 너무 당연스러운 것이라서 Thin Client용어는 근자에는 잘 쓰이지 않는 용어가 되어버린듯 하다.

하지만 Thin Client는 늘 강조해도 지나치지 않는 용어라 생각한다.

물론 프로젝트 성격에 따라 다르긴하겠지만(오해없으시길)..

3-tier의 목적은

서버쪽 정책(비지니스 로직)이 변경된다하여도 클라이언트는 정책에 영향(업데이트없이)받지않고 종전과 동일하게 사용가능하다.

서버쪽 변경으로 인한 클라이언트 변경(업데이트)이 없는 이유는 다름 아닌 Interface만 가지고 있고 구현은 서버단이 책임지고 있기때문이다.

예를 들어

웹서버에서 웹 어플리케이션의 내용(비지니스 로직)이 변경되었다고 웹브라우저를 업데이트하지 않는것과 같은 것이다.

현재에는 어플리케이션의 설계 패러다임이 바뀌었다.

어플리케이션 웹화 되면서 자연스레 저러한 패러다임이 있는지 조차 느낄 수 없을 정도로 당연한듯 설계되지만...

(웹프로젝트는 기본적으로 3-tier입니다. 일반 응용프로그램은 얘기가 다릅니다. 고려되어야겠지요..)

어찌되었던 저러한 C/S 방법론 각광받던 시기가 있었고, 그리 오래전 얘기는 아니다.

이렇듯 Interface의 개념(3-tier의 개념) 필요하게되는 시점에 오기에 이르렀는데..

클라이언트는 Interface만, 서버(혹은 미들웨어라고도 부르는)는 비지니스 로직을..(*중요 별표)

담당(?)하게 된 것이다.

/*

네트웍 환경을 예로 들었지만..작게는 로컬 환경에서도 마찬가지입니다.

윈도우 어플리케이션 제작시.

UI에서 모든 기능을 구현해 놓으면 나중에 버그 잡으려고 할때..

UI 코드와 비지니스 로직과 겹쳐서 무진 애먹습니다.

처음엔 누구나 격는 진통이라 생각합니다..^^

다른쪽 코드 수정으로 인해 이쪽 코드가 영향받지 않도록...하라...

"느슨한 결합" 많이 들어 보셨죠..^^?

*/

RMI(Romote Method Invocation, 원격 메소드 호출)에서는

클라이언트에게 Interface 즉 껍데기만 줘서 어떠한 서비스가 있는지 알려주어(일전에 말하였던 공개)..

서버의 비지니스 로직을 호출하게 되어있다.

굳이 RMI 뿐만 아니라 분산객체라 불리는 것들이 이러한 방법으로 interface를 사용하게되는데...

Interface의 프로토타입이 변경되지 않는한 클라이언트가 변경되어야할 일은 없다.

그러므로 서버의 로직 변경에 클라이언트는 영향받지 않게된 것이다.

그렇다면 Interface가 변경이 되어 버린다면 어떻게 될까?

이전 글에서 Interface는 약속이라 하였다.

서버에서 이 약속을 깨버리면..

음..

Interface가 변경되었다는것은 '클라이언트 변경이 불가피하다'라는것이다.

그래서 한번 배포된 Interface는 함부로 변경(수정, 삭제, 확장을 포함해서)이 되어선 안된다는것이다.

일대 혼란(업데이트 이슈)이 발생..

(첫 배포가 그래서 중요합니다.)

MS쪽에서는 Interface 변경해야할때..

최초에 배포된 Interface는 변경하지 않고 확장만한다.

예를 들어

IXMLDOMDocument

IXMLDOMDocument2(IXMLDOMDocument을 상속하여 좀더 확장된 버전)

이런식으로 Interface를 넘버링으로 구별하여 변경하고 있다.

관심 분야가 아니라도 간혹 이러한 네이밍 룰을 보았을것으로 생각한다.

이는 종전에 배포된(IXMLDOMDocument) Interface는 이미 배포되었으니 그냥 쓰고 ..

새로 App작성시 혹은 업데이트시 IXMLDOMDocument2를 사용하라는 MS의 의도이다.

물론 최초에 IXMLDOMDocument2가 지원하는것을 고려해서 Interface를 작성하는것이 최선안이 되겠지만..

모든것을 예측하기에는 인간은 너무나 부족하다.

결국 이 글의 하고자하는 말은

Interface는 상호간 약속이므로 함부로 변경되어선 안된다는것

(이 한줄까지 오기위한 서론이 너무 길었습니다.^^)

이는 Interface를 설계시 고려해야할 기본 덕목이라 할 수 있다.

여기서 말하고자하는것은

Interface 자체가 중요한게 아니라..

Interface를 사용하는 의미가 중요하다라는것..

이러한 컨셉으로 클라이언트를 더욱 가볍게 하는 것은

Interface를 사용하는 또 하나의 보이지 않는 역할이라고도 할 수 있다.

/*

에필로그

Interface 이야기는 여기까지하고자 합니다..

성원을 보내주신 분들이 계셔서 탄력받아 계획에도 없던 글을 하나 더 올렸습니다.

적고 보니 요즘에는 너무 당연하고 철지난 얘기라..

좀 그렇습니다..^^;

여기서 더 나가면 세부적인 기술 강좌로 가야할것 같습니다...그래서 여기까지만...^^

부담없이 가볍게 읽어 내려갔으면하는 것이 바램입니다만, 그랬는지요..^^?

저는 한때 작가의 길을 걷고자 했던적이 있었습니다. 고등학교때 문학이 너무 좋아서..

나름 문학 소년이었답니다.(이글 작문한걸 보면 안 믿어지실테지만..-_-;;)

그러나 다행히도 그당시에 재능이 없다는걸 빨리 깨닫고 포기를 했더랬습니다.

그때 꿈을 접지 않았다면 지금 굶어 죽었을것 같습니다...-.-;;

지금 생각해도 다행이라 생각합니다..-.-

우스게 소리였습니다...ㅎ..

수고하셨습니다.

워낙 문장력이 없다보니 탈고해주신 분이 있습니다.

special thanx. 꼼

*/

너무나 많은 곳에 쓰이는 단어 인터페이스(Interface)..

UI(User Interface), 프로그래밍 언어에서 부르는 Interface, API, CGI 등..

우리는 가끔 여러 사람 혹은 다른 회사와 공동 프로젝트 진행시

"인터페이스를 맞추자"

"인터페이스를 열어 달라"

"인터페이스 만들어 주세요"

"이렇게 하기로 인터페이스 정해 놓게 왜 인터페이스대로 하지 않습니까?"

이말을 두루뭉술하게 여러곳에 적용해서 아주 빈번히 사용하고 있다.

용어를 설명하는데 있어서 일반 사전적인 의미와 컴퓨터 사전적인 의미는 많이 다르다.

주로 컴퓨터의 용어가 더 많은 의미를 내포하고 있는데..

여러 방면에서 사용하고 있는 말이지만..

프로그래밍 언어에서의 인터페이스의 역할에 대해 그리고

이말을 사용하고 있는 공통적인 의미는 '약속'라는 뜻이 아닐까.?

라는데서 이글을 써내려 가려고한다.

프로그래밍 언어에서 Interface는 무엇으로 사용하는가..

Interface

하면 떠오르는 것들.

폴리모피즘, 상속, 오버라이드, 동적 바인딩

(저는 이런것들이 떠오르네요^^)

본인은 C++을 주력 언어로 사용하고 있지만..

java로 Interface라는 것으로 풀어 보려고한다.

개인적으로는 java가 더 후대 언어라서 인지 C++ 보다는 좀더 언어가 명확하다라고 해야할까? 좀더 과학적이랄까.

(java의 문법자체는 C에서 나온것에 이라는것에는 이견이 없습니다. 따라서 C 문법의 단점 또한 계승하고 있지요..-.-)

암튼 java를 해본지 너무 오래 되긴했지만(달갑진 않지만 지금도 언어 자체가 진화하고 있더군요..), java로 부터 나름대로 느낌점은 그렇다.

(뭐가 더 우수한 언어이고, 뭐가 좋은지에 대한 논쟁은 이 글에서 논하고자 하는 쟁점은 아니므로 있는 그대로만 받아들여 주시기 바랍니다.)

일단 문법적으로 Interface를 파악해 볼까!

java에서 Interface라는 키워드를 적었을때 문법적인 제약이 발생한다.

1. prototype만 기술

2. 자체 객체생성(instance) 할 수 없음.

3. 반드시 sub class에서 구현.

4. 그리고 접근자는 public !!

1~3번 은 문법적인 제약 조건이지만..

4번은 Interface를 사용하는것에 대한 아주 큰 의미를 내포하고 있다.

혹은 Interface를 사용하는 의미의 전부라고도 할 수 있다.

4번으로 인해 1~3이 왜 저러한 제약 조건이 붙은것인지에 대한 이유가 되기도 한다.

java쪽 기술에서 보면 J2EE라는 기술이 있고, API에서는 javax로 따로 분류하고 있는데..

Database관련하여 JDBC라는것이 있다.

Interface를 설명하는데 아주 좋은 예라 할 수 있다.

ODBC도 동일하지만 JDBC만을 예로 들자면

JDBC를 이용하여 개발시 우선 3가지 요소가 존재한다.

1. SUN :  Interface 만 제공

2. DB 벤더 : Interface 구현

3. 개발자 : Interface 활용

우선 SUN사에는 sql을 이용할 수 있는 interface만 만든다(정확히 표현하자면 '명세한다', '공개한다').

DB 벤더는 SUN서 공개한 Interface를 보고 구현을 한다(이것이 드라이버가 되겠지요).

개발자는 드라이버에서 구현된 Interface를 호출해서 쿼리를 던진다.

그럼 가정을 해보자.

SUN에서 Interface를 제공하지 않았다면 어떻게 될까.

A라는 DB 벤더는 독자적인 인터페이스를 만들어서 함수를 제공할것이다.

B라는 DB 벤더 또한 독자적인 인터페이스를 만들어서 함수를 제공할것이다.

C 벤더 또한 마찬가지로 독자적인 구현...

(아...우울해지겠죠...그쵸..?)

예를 들어 각 회사에서 쿼리를 실행하는 함수 다음과 같이 정의 했다.

A: runExec(string str)

B: RunQuery(String str)

C: ExcuteQuery(String str)

이와 같이 각 벤더가 정의 했다면 개발자는 각 벤더의 API문서를 봐야 할것이다.

왜 냐하면 Interface가 모두 다르기 때문에..

(이런것들을 native driver라 부르지요..)

좀더 들어가서 개발자는 위 세가지 DB를 모두 지원하는 어플리케이션을 만든다고 가정한다면..

if문의 분기 처리로 호출할것인지.. 이때부터 난잡해지는 코드에 고민에 빠지게 된다.

하지만 JDBC를 이용하면 SUN에서 Interface를 공개(혹은 제약) 했기때문에...

각 DB 벤더는 그 Interface 명으로 Interface를 자사의 DB에 맞게 각기 구현해야만한다.

따라서 개발자는 각 벤더가 어떻게 구현했는지 알 필요가 없다.

개발자는 각 DB 벤더가 어떻게 구현했는지는 몰라도 "나는 이 Interface만 호출하면 원하는 결과를 얻을 수 있다"라는 것을 알고있다.

각 벤더의 API문서를 볼 필요도 없고(아주 가끔은 필요할 수 도..) 개발자는 SUN에서 제공한 Interface에대한 명세만 보면 되니까.

'SUN에서 Interface라는 제약을 뒀기 때문에 각 벤더가 자사의 DB에 맞게 구현됐다'라고 보장을 받을 수 있기 때문이다.

언어의 문법상 Interface는 상속하여 반듯이 구현해야 하기 때문에 각 DB 벤더는 알아서 구현했을 것이다.

그럼 여기서 초반부에 Interface는 '약속'이다라고 무작정 정의해버린 문장에 부합된다고 볼 수 있지 않을까.

여기서 Interface를 다른 말로 바꾸어 보면..

Interface는

약속이다.

공개이다.

명세이다.

규약이다.

프로토콜이다.

모두 맞는 말이 아닐까..

위에서 나열한 1~4에 대한 내용이 4이기 때문에 1~3이 그렇게 될 수 밖에 없다는것에 대한 이유가 된다고 볼 수 있다.

아주 간단하게 정리해보자

Interface는 어떻게 구현됐는지는 모르지만, Interface만 호출하면 원하는것을 얻을 수 있다.

그러므로 인터페이스 공개(public)가 아닌것이 의미가 있을까!!

("공개가 아닌 인터페이스는 의미가 없다"라고 정의 해도 되겠지요?)

Interface를 활용한기술이 또 무엇이 있을까?

RMI

CORBA

COM

EJB

...

...

위 기술중 한가지는 반듯이 써봤을것을 믿어 의심치 않는다.

COM을 사용하면서 우리는 COM에서 제공한 Interface만 보고 작성한다.

어떻게 작성되어 있는지 우리는 알지 못하지만, Interface를 호출하면 된다는것 만큼은 알고있기 때문에..

왜냐하면 그렇게 약속했으니까, 규약했으니까, 공개했으니까.



출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=128&page=3

프로젝트 진행시 XML을 많이 쓰나요..?

저는 대부분의 프로젝트에서 XML을 활용하고 있습니다.

제가 XML을 처음 접한것은...1999년도에 학교 친구들과 코엑스 IT전시회가서 입니다.

교수님이 코엑스 갔다오면 결석한 수업 그것으로 인정해 주겠다 해서..-_-;;

전시회에서 윈도우, 웹 어플리케이션으로 XML에 있는 데이터를 찾고, 갱신하는것 보여 주었습니다.

그때 당시에는 별로 감흥이 오지 않았었죠.

그러다 졸업 후 한국 SUN으로 부터 XML관련 강의를 들을 수 있는 기회가 있었는데.

크게 깨달음은 없었으나 XML의 전반적인 기초 지식을 배우게 되었지요..

본격적으로 하게 된것은 아마도 처음 들으시는 분들도 있겠지만 MPEG21 프로젝트 참여에서 부터였습니다.

이 MPEG21은 아마도 현재까지도 표준화를 진행하고 있을것 같네요..

MPEG21은...컨텐츠를 XML로 정의(생성)하고 있습니다.

이때부터 본격적으로 XML을 하게되었는데..

그 이후 부터는 엥간한 데이타 처리나 데이타 전송은 XML로 전달하고 있습니다.

그 편함에 빠진것이지요..

XML을 사용하기 이전에는 데이타 영속성을 처리를 위해

보통은 file data, ini, 레지트리등을 사용하였습니다.

(물론 DB를 사용해도 되겠지요.. 전 주로 기업용 보다는 일반 사용자용 app를 주로 작성하였답니다.)

file data(대부분 처음 시작은 이것으로 시작하죠..)로 데이타 영속성 처리하기 위해서는

app(어플리케이션)이 읽을 수 있도록 프로그래머가 데이타 포멧을 정의 해야하는데..

대강 이런식으로..

A;Hankyun;pnca@test.com;10

B;Hankyun2;pnca2@test.com;20

각 데이타를 분리해 내기위해 ';'으로 분리하고,

각 레코드을 분리하기위해서는

파일을 한줄씩 라인단위로 읽을것인지,

버퍼로 모두 읽어 들여 라인 피드로 각 라인을 구분할 것인지 살짝 고민에 빠진다.

위와 같은 정도 수준의 간단한 데이타 구조라면 그냥 할만하다..-.-;

하지만 다음의 이미지 처럼 데이타가 상위 종속을 가진 트리구조(hierarchy 구조) 라면..?

그렇다면 레지스트리?

레지스트리는 데이타를 트리구조로 가지고 있으므로 위와 같은 상속 구조의 데이타를 표현해 낼 수 있다.

가능은 하다...하지만 레지스트리가 미로가 될것이다..

부사수가 "레지스트리로 가능한데 이걸로 하시죠"라는 주장에...사수를 설득하기란 쉽지 않을겁니다...-.-;

이건 딴얘기인데..

더 큰 문제는 윈95 부터 현재 2000을 거쳐 비스타까지 레지스트리를 쓰면서 문제가 없었나요..?

윈도우 버전에 따른 레지스트리 접근 및 구조가 조금 바꼈습니다.(조금이지만 개발자에게 와 닿는 파장은 적지 않았습니다.)

9x에서 잘 돌아가던것이 2000에 가서는 제대로 돌지 않는것이 태반(너무 비약했나..-.-)이었습니다.

뿐만 아니라 x64 OS가 릴리즈 됨에 따라 생각할 것이 많아 지죠(레지스트리를 x86, x64따로 관리 합니다.).

그리고 레지스트리에 대한 접근 권한도 문제가 심심치 않게 발생하기도 하죠..

win 2000이후의 OS부터는 레지스트리 이슈는 정말 다행스럽게도 많이 줄었으나, 과거 9x -> 2000으로 변경되는 격동기가 있었습니다.

더군다나 이 와중에 NT4 이슈도 정말 만만치 않았습니다...-.-;

이 격동기에 오죽했으면 "나 앞으로 OS 하나 더 나오기 전에 이바닥 뜬다"라는 말도 했던 기억있습니다...-.-;;

물론 저의 실력이 미천하여 문제가 많았을 수 도....-.-;;

아..다 귀찮다...

그동안 험난한 길을 걸어온 김군은 이제 데이타 처리는 전부 XML로..라고 자신에게 조용히(누가 들어줄리 만무하기에) 선언을 합니다.~( '')

다시 본론으로... 

XML은 기본적으로 MS에서 파서를 제공해줍니다.

IE 5.0 이상인 PC에서는 파서가 들어있었던것으로 기억합니다..

그래서 현재의 대부분의 PC에서는 XML을 사용하는데 별 문제가 되지 않습니다.

그리고 MSXML, tinyXML, 기타 여러 XML 파서들이 존재합니다.(저는 한 서너개 써본듯)

저는 MS에서 제공하는 MSXML파서를 좀더 구현해서 편하게 래핑한 클래스를 사용합니다.

물론 처음에는 쉽지 않습니다..COM의 낯선 코드들, 더 힘들게 하는건 MSDN이 JS기준의 샘플로 되어 있어서...-.-;

하지만 한번만 제대로 만들어 두면 두고 두고 써먹을 수 있습니다.

전 5년 동안 써먹고 있습니다...뿌듯..-.-y

제가 XML을 데이타로 사용하는 가장 큰 이유는..

직접 파싱할 필요도 파싱하기 위한 포멧을 생각할 필요도 없습니다.

데이타 구조(좀 있어보이는듯 한  용어로는' 메타데이타')만 생각하면 됩니다.

주소만 주면 파서가 데이터를 찾아 오니까요..

XPath를 이용하여 아이템이 몇개 존재하는지, 엘리먼트 및 속성의 값 뽑아오기,

엘리먼트 및 속성을 추가, 수정, 삭제 등 아주 쉽게 데이트를 조작할 수 있지요.

하여,

소켓으로 데이타 전송시에도 간단한 데이타의 경우 바이트에 담아서 보내는데...

복잡한 데이타의 경우 XML로 데이타를 구성하여 바이트에 담아서 전송하는 프로젝트를 종종 보았습니다.(당연?)

그리고 규모가 큰 서버들의 경우에는 대부분 환경 정보들을 XML을 데이타로 사용하고 있습니다..

예를들면,

아파치 서버가 처음에는 일반 텍스트로 환경정보를 관리하다가 현재(?)는 XML로 환경 설정값을 데이타로 사용하고 있지요...

웹로직도 그렇습니다.

위 두 경우로 일반화할 순 없지만...사실입니다.

이렇듯 복잡한 데이터 구조를 가지고 있는 경우

XML 구조로 데이터를 가지고 있다면 데이타를 파싱해내기 무지 쉽기 때문이죠..

그 편함에 한번 빠져 보시죠...^^

대부분의 개발자 분들은 XML을 알고 계십니다..다만 활용은...음...

XML자체는 어떠한 기술보다 쉬우며, 적은 시간의 투자로 많은것을 얻을 수 있는것이 XML이라 생각합니다.

물론 세상엔 쉬운게 없습니다.

더 깊이 들여다 보면,

지금은 너무 복잡하여 사용하고 있지 않지만 DTD라는 것도 있고

XML  Schema

XSL or 스타일 시트

등 XML과 연관된 것들이 있습니다.

하지만 영속성을 위한 데이타용으로써는 XML자체만으로도 충분하다 생각합니다.

그리고 XML의 사용 용도는 아주 다양한데..

이를 기초로 해야할것이 녹녹치 않을 정도로 용어나 기술들의 응용 분야가 많습니다.

SOAP, EJB, SmallTalk...등등

엔터프라이즈 환경에서 XML은 아주 다양한 용도로 사용되고 있습니다.

관심이 있다면 관련 강좌를 한번쯤 찾아서 읽어 보시는것도 좋을 것 같네요...^^

네...

아주 다양한 곳에 사용되고 있지요...

다양한 곳에 사용하고 있지만, XML을 사용하는 공통적인 목적은 하나입니다.

그것은 데이타



출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=139&page=3