Yi

Developers who are accustomed to the IDisposable pattern or to C#’s ‘using’ syntax sometimes ask why COM Interop doesn’t support IDisposable on every Runtime Callable Wrapper (RCW).  That way, managed code could indicate that it is finished using the unmanaged COM resource.  This would allow the resources to be cleaned up much earlier than they would be if we waited for a GC.  Also, it might better approximate the way an unmanaged client would have used this COM object through explicit Release calls.

There’s a service called System.Runtime.InteropServices.Marshal.ReleaseComObject() that looks suspiciously like it could be used as a Dispose() call.  However, this is misleading.  ReleaseComObject is quite different from Dispose() and it’s also quite different from IUnknown::Release() as I’ll explain.

The COM Interop layer in the CLR can make do with a single reference count against the unmanaged pUnk, regardless of how many managed clients refer to that object.  In other words, the Interop layer does not hold a reference count for each managed client of that pUnk.  Instead, we rely on the reachability magic of the GC to determine when nobody needs that pUnk anymore.  When nobody needs the pUnk, then we drop our single reference count on that pUnk.

Furthermore, negotiation for interfaces in managed code via COM Interop does not necessarily affect the unmanaged refcount of the COM object.  For instance, the managed wrapper might have already cached a pUnk for this interface.

Regardless of the actual refcount that the wrapper holds on the underlying COM object, ReleaseComObject will release all these refcounts at one time.

However, the return value from ReleaseComObject reveals that there’s an additional refcounting scheme involved.  This is unrelated to the COM refcount.  The same pUnk might be marshaled into the managed process a number of times.  We keep track of this count.  You can then call ReleaseComObject that same number of times before we will call IUnknown::Release on the pUnks held by the wrapper and start giving throwing InvalidComObjectExceptions.  If you are passing the pUnk backwards and forwards across the layer, this means that the “marshaling count” will be a large and arbitrary number.  But, for some usage patterns, the number of times the pUnk is marshaled across may correspond to the number of distinct managed clients that have got their hands on the wrapper.  If this happens to be the case, then that many managed clients can independently call ReleaseComObject before the wrapper is zombied and the underlying pUnks are Release’d.

I guess that this behavior is slightly more useful than a simple Release in some circumstances.  And you can turn it into the equivalent of IUnknown::Release by calling it in a loop until it returns 0.  At that point, our internal “marshaling count” has been decremented to 0 and we have Release’d the pUnks.  (We really need to add a ReleaseComObjectFully() service to avoid that silly loop).

Application code can either be on the GC plan, where we track whether there are references outstanding – but in a non-deterministic manner that is guided by memory pressure – or application code can do the tracking itself.  But if the application does the tracking, it is responsible for knowing whether there are other managed clients still using the COM object.

One way you might do this is by subtyping the wrapper and adding a Dispose protocol on the managed side that is reference counted.  But all managed clients in the process must observe the discipline you define.  A more practical approach is to ensure that you are the only client of the pUnk by creating the COM object yourself and then never sharing that reference with anyone else.

If you are using a COM object in a scoped, single-threaded manner then you can safely call ReleaseComObject on that object when you are done with it.  This will eagerly release any unmanaged resources associated with that object.  Subsequent calls would get an InvalidComObjectException.  So don’t make subsequent calls.

But if you are using a COM object from multiple places or multiple threads in your application (or from other applications in the same process), you should not call ReleaseComObject.  That’s because you will inflict InvalidComObjectExceptions on those other parts of the application.

So my advice is:

1)      If you are a server application, calling ReleaseComObject may be an important and necessary requirement for getting good throughput.  This is especially true if the COM objects live in a Single Threaded Apartment (STA).  For example, ASP compatibility mode uses the DCOM STA threadpool.  In these scenarios, you would create a COM object, use it, then eagerly call ReleaseComObject on each request.

2)      If you are a client application using a modest number of COM objects that are passed around freely in your managed code, you should not use ReleaseComObject.  You would likely inflict Disconnected errors on parts of the application by doing so.  The performance benefit of eagerly cleaning up the resources isn’t worth the problems you are causing.

3)      If you have a case where you are creating COM objects at a high rate, passing them around freely, choking the Finalizer thread, and consuming a lot of unmanaged resources… you are out of luck.

프로퍼티(property)는 자바나 C++에는 없는 기능으로, 클래스외부에서 보면 멤버변수처럼 보이고,클래스내부에서 보면 메소드처럼 보이는 것이다.

■프로퍼티사용법

엑세스레벨 형 프로퍼티이름
{
  set
  {
    //  set엑세서
    //  여기에 값이 변경될때 처리를 쓴다.
    //  value 라고 하는 이름의 변수에 대입된 값이 들어간다.
  }
  get
  {
    //  get엑세서
    //  여기에 값을 얻을때 처리를 쓴다.
    //  메소드의 경우와 같이 값은 return 키워드를 사용해서 돌려준다.
  }
}

예를 들어 실제로 클래스를 이용하는 쪽의 코드는 복잡해진다.

■프로퍼티를 사용하지 않은 클래스

using System;
//실체를 숨겨서 만든 복소수 클래스

class Complex
{

  //실체는 외부에서 숨김(private로 해놓는다.)
  private double re; // 실수부를 기억해 놓는다.
  private double im; // 허수부를 기억해 놓는다.
  public double Re(){return this.re;}    // 실수부를 꺼낸다.

  public void Re(double x){this.re = x;} // 실수부를 바꿔쓴다.
  public double Im(){return this.im;}    // 허수부를 꺼낸다.
  public void Im(double y){this.im = y;} // 허수부를 바꿔쓴다.

  public double Abs(){return Math.Sqrt(re*re + im*im);}  // 절대값을 꺼낸다.
}

// 클래스를 사용하는 쪽
class ConcealSample
{
  public static void Main()
  {
    // x = 5 + 1i
    Complex x = new Complex();
    x.Re(5);  // x.re = 5
    x.Im(1);  // x.im = 1

    // y = -2 + 3i
    Complex y = new Complex();
    y.Re(-2); // y.re = -2
    y.Im( 3); // y.im =  3

    Complex z = new Complex();
    z.Re(x.Re() + y.Re()); // z.re = x.re + y.re
    z.Im(x.Im() + y.Im()); // z.im = x.im + y.im

    Console.Write("|{0} + {1}i| = {2}\n", z.Re(), z.Im(), z.Abs());
    // |3 + 4i| = 5 로 표시됨

  }
}

위의 복소수 클래스를 프로퍼디를 이용해서 바꿔쓰면 아래와 같다.

■프로퍼티를 사용하는 클래스

using System;
// 클래스정의
class Complex
{
  // 실체를 외부로 부터 숨김(private로 해놓는다.)
  private double re; // 실수부를 기억해 놓는다.
  private double im; // 허수부를 기억해 놓는다.

  // 실수부 취득,변환용 프로퍼티
  public double Re
  {
    set{this.re = value;}
    get{return this.re;}
  }
  /* 위의 코드의 의미는 아래와 같다.
  public void SetRe(double value){this.re = value;}
  public double GetRe(){return this.re;}
  메소드와 같은 감각으로 사용한다.
  */

  // 실수부를 취득,변환용의 프로퍼티
  public double Im
  {
    set{this.im = value;}
    get{return this.im;}
  }

  // 절대값의 취득용 프로퍼티
  public double Abs
  {
    // 읽기 전용 프로퍼티
    // set 블록을 쓰지 않는다.
    get{return Math.Sqrt(re*re + im*im);}
  }
}

// 클래스를 이용하는 쪽
class PropertySample
{
  public static void Main()
  {
    Complex c = new Complex();
    c.Re = 4; // Re프로퍼티의 set 엑세스를 불러낸다.
    c.Im = 3; // Im프로퍼디의 set 엑세스를 불러낸다.
    Console.Write("|{0} + ", c.Re); // Re프로퍼티의 get엑세스를 불러낸다.
    Console.Write("{0}i| =", c.Im); // Im프로퍼티의 get엑서스를 불러낸다.
    Console.Write(" {0}\n", c.Abs); // Abs프로퍼디의 get엑세스를 불러낸다.
  }
}

■get/set에 다른 엑세스레벨을 설정

Ver.2.0
C#2.0에서 부터 프로퍼티 엑세스의 get/set 에 다른 엑세스레벨을 설정하는 것이 가능하게 되었다.
예를 들어,

class A
{
  private int n;

  public int N
  {
    get{ return this.n; }
    protected set{ this.n = value; }
  }
}

■자동프로퍼티

Ver.3.0
C#3.0 에서는 프로퍼티 get/set의 내용을 생략해도 될수있게 되었다.
이 기능을 자동프로퍼티(auto-property,auto-implemented property)라고 한다.
예를 들면,
public string Name { get; set; }
이라고 쓰면,
private string __name;
public string Name
{
  get { return this.__name; }
  set { this.__name = value; }
}
위와 같은 코드가 자동적으로 생성되어진다.(__name의 변수는 프로그래머는 참조할수 있는것은 아니다.)

1. 클라이언트 콜백을 사용하는 페이지의 제작 과정

- ICallbackeventHandler 인터페이스 구현

- 서버로 콜백을 일으키는 클라이언트 스크립트 등록

- 서버의 응답을 처리하는 스크립트

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

2. 콜백 함수를 호출했을때 실행되는 메서드

-RaiseCallbackEvent 메서드

--> 클라이언트에서 전달한 값을 eventArgument 인자로 받아서 처리

- GetCallbackResult

--> 클라이언트로 전달할 데이터를 반환하는 메서드

2.1.

RaiseCallbackEvent 메서드가 먼저 호출됨.

클라이언트에서 전달한 값이 eventArgument 인자로 넘어온다.

이 메서드에서는 필요한 처리를 한 후에 처리결과를 클래스 내부 변수에 저장해야한다.

즉, RaiseCallbackevent는 클라이언트로 전달할 값을 반환하지 못하기 때문이다.

그 다음 GetCallbackResult는 RaiseCallbackEvent에서 저장된 내부 변수 값을 반환한다.

이 메서드에서 반환한 값은 클라이언트로 전달된다.

ICallbackEventHandler 인터페이스는 클라이언트에서 인자를 받아 처리하는 메서드(RaiseCallbackEvent)와 클라이언트로 결과를 반환하는 메서드(GetCallback Result)로 나뉜다는 점을 잘 파악해 두기 바란다. (-0-;)

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

3. 서버로 콜백을 일으키는 클라이언트 스크립트 등록

- 클라이언트 콜백은 XMLHttpRequest 컨트롤을 이용해서 수행

- 클라이언트 콜백용 API를 이용해서 생성

- GetCallbackEventReference

public string GetCallbackEventReference(Control control, string argument, string clientCallback, string context)

- argument의 값을 서버로 전달할 값을 나타내는 클라이언트측 표현

- argumetn의 값은 서버의 RaiseCallbackEvent 메서드 인자로 전달

- clientCallback은 GetCallbackResult 메서드의 반환 값을 받아 처리할 클라이언트 함수의 이름

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

4. 서버의 응답을 처리하는 스크립트

- 서버의 응답을 처리할 스크립트 함수의 이름은 GetCallbackEventReference 메서드의 clientCallback 인자로 지정된다

- 첫번째 인자는 서버의 처리결과 값, 두번째 인자는 context값

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

5. isCallback

페이지가 콜백에 의해 실행중일때 isPostBack 속성도 true값을 반환

- isCallback이 true일 때에는 페이지가 렌더링 처리를 하지 않는다

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

6. 그외

- 클라이언트에서 콜백 요청을 하는 함수는 WebForm_DoCallback

-

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

public partial class _Default : System.Web.UI.Page, System.Web.UI.ICallbackEventHandler
{
    protected string cbReference;
    protected string callbackReturn;
    protected string callbackParam;   

    protected void Page_Load(object sender, EventArgs e)
    {

        if (!IsPostBack)
        {
            txtCount.Text = "0";
        }

        if (!IsCallback)
        {
            //cbReference = Page.ClientScript.GetCallbackEventReference(this, "document.getElementById('" + this.txtClientCallBack.ClientID + "').value", "ReciveFunc", "'콜백성공'");

            cbReference = Page.ClientScript.GetCallbackEventReference(this, "init", "ReciveFunc", "'콜백성공'");
        }
    }

    void ICallbackEventHandler.RaiseCallbackEvent(string eventArgument)
    {

        //eventArgument를 이용한 처리

        callbackParam = "(" + eventArgument + ") 를 입력";

         //ConnectDataBase(int.Parse(eventArgument));
    }

    string ICallbackEventHandler.GetCallbackResult()
    {

       // 처리 결과를 반환
        return callbackParam;
    }

  <script type="text/javascript" language="javascript">
   
    var init = 0;
   
    function ReciveFunc(val, context)
    {
        //<!-- 서버에서 보내준 데이터를 전달 받는 녀석? -->      
       
        div3.innerHTML = val;             
       
        init += 10;       
    }
   
    </script>
</head>

<body>
    <form id="form1" runat="server">   
        <div id="div1">
            <asp:Button ID="btnPostBack" runat="server" Text="포스트백" OnClick="btnPostBack_Click" /> <br />
            <asp:TextBox ID="txtClientCallBack" runat="server" ></asp:TextBox> <br />
            <button onclick = "<%= cbReference %>"> 클라이언트 콜백</button> <br />
            반환값 : <span id="returnValue"></span>          
        </div>

화폐단위나 하드디스크용량등을의 숫자값은 상당히 길때가 있습니다. 이럴 때 보는 사람이 구분하기 쉽게 하기 위해 3자리씩 구분자를 넣어 표시해주는 경우가 있습니다.

예를 들어 1234567890란 값이 있다면 1,234,567,890로 보여주고 하는 경우를 말합니다.

.NET에서는 이런 숫자값을 3자리씩 구분자를 넣어 문자열로 변환하고자 한다면, 정적인 메소드인 Format을 이용하면 간단하게 해결됩니다.

String.Format("{0:#,0} 원", 1234567890);

이 메소드의 2번째 파라미터로 지정된 1234567890는 변환전의 숫자값이고 첫번째 파라미터는 지정한 문자열을 {0:#,0}는 서식을 지정한 항목을 말합니다.

0:#,0의 의미를 설명해보면,

인덱스 0번째는 Argument로 지정된 숫자를 그 정수부분에 각 그룹별 간 단락문자(,)를 넣고 변환한다는 의미입니다.

출력된 문자열로 단락을 구분하는 문자가 넣어지게 되는 것은 서식지정항목으로 단락기호(,)가 지정되어 있기 때문입니다.  ,이전에 #은 자릿수홀더라고 말하며 ,이후에 0은 제로홀더라고 말하는데 이 두가지 조건이 구비되어 있어야지 정확한게 실행됩니다. 그렇기 때문에 #,0이라고 적는 것입니다.

[WonCheck.cs]

using System;
using System.Collections.Generic;

namespace WonCheck
{
    class Program
    {
        static void Main(string[] args)
        {
            int num = 987654321;
            string s = String.Format("{0:#,0} 원", num);
            Console.WriteLine(s);
        }
    }
}

*응용 프로그램에서 구성 요소를 사용하려면 해당 구성 요소에 대한 참조를 추가해야함.

*참조추가 대화상자의 다섯가지 옵션
-.NET : 참조에 사용할 수 있는 .NET Framework 구성 요소를 모두 나열
-COM : 참조에 사용할 수 있는 COM 구성 요소를 모두 나열
-프로젝트 : 로컬 프로젝트에서 생성된 다시 사용가능한 구성 요소를 모두 나열
-찾아보기 : 파일 시스템에서 구성 요소를 찾아볼 수 있음
-최근에 사용한 파일 - 최근에 컴퓨터의 프로젝트에 추가한 구성 요소 목록이 있음

*기본적으로 참조 추가 대화 상자에는 공용 어셈블리 폴더(Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies) 또는 GAC(전역 어셈블리 캐시)에 있는 어셈블리의 목록만 표시됨.
-참조 경로를 추가하면 사용자 고유의 어셈블리를 목록에 추가할 수 있음

**동일 솔루션에 있는 다른 프로젝트의 출력에 대한 파일 참조를 추가하면 컴파일 오류가 발생할 수 있으므로 비추천
**참조 추가 대화 상자의 프로젝트 탭을 사용하여 프로젝트 간 참조를 만들면 프로젝트에서 만드는 클래스 라이브러리를 보다 효율적으로 관리할 수 있으므로 개발 팀이 작업하기가 간편해짐
**GAC에 등록되어 있는 사용자 지정 구성 요소에 대한 참조가 포함된 응용 프로그램을 배포/복사하는 경우 구성 요소는 CopyLocal 설정과 상관없이 응용 프로그램과 함게 배포/복사되지 않음

*참조를 추가하려면
1.솔루션 탐색기에서 프로젝트의 My Project 노드를 두 번 클릭합니다.
2.프로젝트 디자이너에서 참조 탭을 클릭합니다.
3.참조 추가 단추를 클릭하여 참조 추가 대화 상자를 엽니다.
4.참조 추가 대화 상자에서 참조할 구성 요소의 종류를 나타내는 탭을 선택합니다.
5.참조할 구성 요소를 위쪽 창에서 선택한 다음 확인을 클릭합니다.

*참조를 제거하려면
1.솔루션 탐색기에서 프로젝트의 My Project 노드를 두 번 클릭합니다.
2.프로젝트 디자이너에서 참조 탭을 클릭합니다.
3.참조 목록에서 제거할 참조를 선택합니다.
4.제거 단추를 클릭합니다.

*참조 경로를 설정하려면
1.솔루션 탐색기에서 프로젝트의 My Project 노드를 두 번 클릭합니다.
2.프로젝트 디자이너에서 참조 탭을 클릭합니다.
3.참조 경로 단추를 클릭합니다.
4.폴더: 필드에서 구성 요소가 포함된 폴더의 전체 경로를 입력합니다.
5.폴더 추가 단추를 클릭한 다음 확인을 클릭합니다.

*외부 구성 요소에 대해 코드를 작성하려면 먼저 해당 구성요소에 대한 참조를 프로젝트에 포함 시켜야함.

*구성 요소에 대한 참조 종류
-.NET Framework 클래스 라이브러리 또는 어셈블리
-COM 구성 요소
-동일한 솔루션에 있는 다른프로젝트의 클래스 라이브러리
-XML WebServices

*공유 구성 요소에 대한 참조
-런타임에 구성 요소는 프로젝트이 출력 경로나 GAC(전역 어셈블리 캐시)중 한 곳에 있어야 함.
-프로젝트에 포함된 개체 참조가 이 위치에 업승면 프로젝트를 빌드할 때 참조를 프로젝트의 출력 경로로 복사해야 함.
-CopyLocal 속성 : 복사 작업이 수행되어야 하는지 여부를 나타냄(true : 참조가 복사, false : 참조 복사 안함)
--어셈블리 구성 요소가 전역 어셈블리 캐시에 있거나 프레임워크 구성 요소인 경우 기본적으로 CopyLocal 속성은 false로 설정. 프로젝트 간 참조는 항상 true로 설정됨.
-GAC에 등록되어 있는 사용자 지정 구성요소에 대한 참조가 포함된 응용프로그램을 배포하는 경우 구성 요소는 CopyLocal설정과 상관없이 응용 프로그램과 함게 배포되지 않음.
-어셈블리를 수동으로 /Bin 폴더에 추가해야 함.(모든 사용자 지정 코드는 정밀하게 조사되고, 익숙하지 않은 사용자 지정 코드를 게시하게 될 위험이 줄어듬.)

*프로젝트 간 참조
-여러 프로젝트를 포함하는 솔루션에서는 한 프로젝트에서 작성된 개체에 대한 참조를 동일한 솔루션의 다른 프로젝트에서 만들 수 있음
-응용 프로그램을 만들고 실행할 때 특별히 고려해야 하는 상호 족속성이 형성됨.

Command.ItemCommand Event
네임스페이스 : System.Web.UI.MobileControls
어셈블리 : System.Web.Mobile(system.web.mobile.dll)
사용자가 ObjectList항목에 연결된 명령을 선택하면 이 이벤트가 발생

ItemCommand 이벤트 처리기가 정의 되어 있는 경우 Command컨트롤은 사용자와의 상호 작용을 통해 항목 이벤트가 생성되면 처리기에 알림.
Click이벤트와 달리 ItemCommand 이벤트는 부모 컨트롤에 버블링 됨.
ItemCommand 이벤트 렌더링은 장치마다 다르다
OnItemCommand 이벤트는 OnClick 이벤트 다음에 발생.
사용자가 명령 단추를 클릭할 때마다 동일한 동작을 반복하는 시나리오에서 Command컨트롤의 CommandName 또는 CommandArgument 속성을 사용하여 어떤 명령 단추가 클릭되었는지 확인할 수 있음.

Hungarian
-소문자 변수 특성에 맞게 소문자 접두어를 사용하고 나머지 Naming은 Pascal형식을 사용하는 Casing
ex) strKoreanName / nCount / txtPostCode

Camel
-첫 시작 단어의 시작 문자는 소문자로 시작하고 새로운 단어의 시작 문자는 대문자로 표기
ex) backColor / postCode

Pascal
-새로운 단어의 시작 문자는 무조건 대문자로 표기 한다.
ex) BackClolr / UserInformation

Upper
-모든 문자를 대문자로 표기 하고 단어 사이의 구문을 _ 혹은 -로 구분한다.
ex)WM_ONKEYDOWN / MAX_VALUE

Lower
-모든 문자를 소문자로 표기하고 단어 사이의 구분을 _혹은 -로 구분한다.
ex)max_value / min_value

Repeater
-웹 서버 컨트롤은 페이지에 사용할 수 있는 데이터로 사용자 지정 목록을 만들 수 있는 컨테이너.
-Rendering 기능 기본 제공되지 않으므로 템플릿을 만들어 Repeater 컨트롤에 대한 레이아웃을 제공해야 함.
-페이지 실행시 Repeater 컨트롤은 데이터 소스의 레코드를 순환하면서 각 레코드에 대한 항목을 렌더링
-다양한 유형의 목록 생성 가능 : 표 레이아웃, 쉼표로 구분된 목록, XML 형식 목록

Repeater 컨트롤에 템플릿 사용
-Repeater컨트롤을 사용하려면 컨트롤 내용의 레이아웃을 정의하는 템플릿을 생성
-태그와 원하는 컨트롤을 원하는 대로 조합하여 템플릿에 포함할 수 있음.
-템플릿이 정의되어 있지 않거나 템플릿에 요소가 포함되어 있지 않으면 응용 프로그램을 실행할 때 컨트롤이 페이지에 나타나지 않음.

Repeater 컨트롤에서 지원하는 템플릿
-ItemTemplate : 데이터 소스의 각 데이터 항목에 대해 한번 렌더링할 HTML 요소 및 컨트롤을 포함함.
-AlternatingItemTemplate : 데이터 소스의 데이터 항목을 하나씩 걸러서 모든 항목을 렌더링할 HTML 요소 및 컨트롤을 포함(일반적으로 ItemTemplate에 지정된 색과 다른 배경색을 지정하는 경우처럼 대체 항목에 대해 다른 모양을 만드는 데 사용)
-HeaderTemplate 및 FooterTemplate : 목록의 처음과 끝에서 각각 렌더링하는 텍스트와 컨트롤 포함.
-SeperatorTemplate : 각 항목 사이에서 렌더링하는 요소를 포함함.

Repeater 컨트롤에 데이터 바인딩
-데이터 소스에 바인딩 되어야 함.
-일반적 데이터 소스 : SqlDataSource, ObjectDataSource 컨트롤과 같은 데이터 소스 컨트롤 들 또는 IEnumerable 인터페이스를 구현하는 클래스에 Repeater 컨트롤을 바인딩 할 수 있음.
-방법 : Repeater 컨트롤 전체에 대한 데이터 소스를 지정
-추가 : 템플릿에 Label 또는 TextBox 컨트롤을 추가할 경우에는 데이터 바인딩 구문을 사용하여 각 컨트롤을 데이터 소스에서 반환된 항목의 필드에 바인딩 함.

ID : 서버측 컨트롤을 인식하기 위한 고유 아이디
ClientID : 렌더링된 페이지의(HTML페이지) 컨트롤을 인식하기 위한 고유 아이디

-단일페이지에서 ID만 사용한다고 해서 일어나는 문제는 없음
-흔히 사용하는 유저 컨트롤과 마스터 페이지 등에서 사용할대 문제 발생
예)test1.aspx 페이지의 TextBox1과 test2.aspx 페이지의 TextBox1이라는 컨트롤이 있을때
TextBox1의 Text값을 가져오라고 할때 test1, test2페이지 중에서 값을 가져올 때 ClientID가 필요

사용 예) <%=아이디명.ClientID%>

PostbackUrl
네임스페이스 : System.Web.UI.Webcontrols
어셈블리 : System.Web(system.web.dll)
-Button 컨트롤을 클릭했을 때 현재 페이지에서 게시할 웹 페이지의 URL을 가져오거나 설정함
-속성값 : Button 컨트롤을 클릭했을 때 현재 페이지에서 게시할 웹 페이지의 URL. 기본값 : 빈 문자열("")이며, 이 경우 자신에게 다시 게시됨
-페이지간 게시를 수행할 수 있음, Button 컨트롤을 클릭할 경우 게시될 위치의 웹 페이지를 PostBackUrl 속성을 사용하여 지정
예)postbackurl="~/page2.aspx"를 지정, Button컨트롤이 포함된 페이지가 Page2.aspx에 게시, 속성 값 미지정시 자신에게 다시 게시됨

Redirect 메서드
네임스페이스:System.Net
어셈블리:System(system.dll)
-클라이언트를 지정된 URL로 리디렉션하도록 응답을 구성
-매개 변수 : url (클라이언트가 요청한 리소스를 찾는데 사용할 URL)
-Redirect 메서드는 클라이언트를 새로운 리소스 위치로 리디렉션 하는데 사용.
-응답의 Location 헤더를 url로 설정, StatusCode 속성을 Redirect로 설정, StatusDescription 속성을 "Found"로 설정

델리케이트,이벤트,어트리뷰트

2009.01.20   c# 세미나   작성자 : 손창효         
서문

윈도우 운영체제는 이벤트 드리븐 방식을 지원
닷넷 환경도 이벤트 드리븐 방식의 윈도우 프로그램을 작성할수 있다.
닷넷 윈도우 프로그램을 작성하려면 델리게이트와 이벤트 개념을 반드시 알고 있어야 할것이다.
델리게이트와 이벤트 개념 및 활용 방법에 대해 알아 보겠다.
또한 프로그램에 필요한 정보를 제공하는 어트리뷰트에 대해서도 살펴보자.
델리게이트

정의 : ‘위임’ 또는 ‘대리자’
c/c++에서 사용하는 함수 포인터와 동일한 개념.
c#에서 델리게이트는 메서드의 포인터(메서드 이름)를 저장할 뿐 내부에 코드를 기술하지는 않는다.
닷넷 프레임워크에서는 이벤트와 함께 사용. 이번트 처리에 많이 이용
인터페이스와 유사
delegate 키워드사용

public delegate [메서드 이름];

델리게이트
델리게이트는 호출 할 메서드와 시그너쳐가 정확하게 일치해야 한다.
두 정수를 입력 받아 그 값을 더해 반환하는 Add()메서드가 있다면

이 메서드의 호출을 대리할 델리게이트는 다음과 같은 형태가 되어야한다.

public int Add(int a, int b)

{

return a + b;

}

delegate int AddDelegate(int a, int b);

델리게이트

주의할점 : 델리케이트는 대리할 메서드와 이름은 같지 않아도 되지만 반환형과 매개변수 타입 및 개수 등은 반드시 일치 해야 한다.
델리게이트 ; 델리게이트 사용하기

시그너처가 동일한 다른 메서드를 호출하고 싶다면 new연산자를 이용해 해당 메서드를 지정

델리게이트 ; static 메서드를 호출하는 델리게이트

델리게이트 ; 델리게이트 등록/제거

델리게이트의 등록/ 제거

델리게이트를  등록하려면 +=연산자
델레게이트를 제거하려면 -=연산자
이벤트 처리

정의 : 특정 사건이 발생됐음을 알리는 메시지 .
마우스 클릭, 키보드 누름 등 특정 사건이 발생하면 운영체제나 해당 프로그램은 사건의 종류에 따라 특정 메시지를 발생.
이벤트는 객체와 같이 사용되며, c#에서는 event 키워드를 통해 이벤트처리

public delegate void MyDelegate();

private event MyDelegate ExamEvent;

이벤트 처리

event는 델리게이트 객체 선언에 덧붙여 선언. +=, -=연산자를 이용해

이벤트 핸들러를 등록 및 제거

event 핸들러는 다음 형태로 정의

object sender : 보통 호출한 객체를 가리키는 this가 사용됨.
EventArgs args : 이벤트 핸들러 파라미터
 
ExampleClass obj = new ExampleClass();

ExamEvent += new MyDelegate(obj.Method);

public delegate void EventHandler(object sender, EventArgs args)

이벤트 처리과정

델리게이트 객체 선언

이벤트 핸들러 구현(처리할 함수 구현)

이벤트에 델리게이트 객체(이벤트 핸들러)등록

이벤트 선언
 
public delegate void Defeat();

private event Defeat EnemyDetected

Defeat라는 델리게이트와 EnemyDetected라는 이벤트 정의.

EnemyDetected라는 이벤트가 발생하면 Defeat 델리게이트를 호출

이벤트 발생을 위한 지침

‘On + 이벤트 명’
OnEvent 메소드는
1.이벤트를 조사하고 어떤 등록 객체가 있는지 검사하고 아무도 없다면 종료
2.등록된 델리게이트에게 전달할 필요가 있는 인자들을 정리하고 적절한 EventArgs 객체에 집어 넣는다.
3.이벤트를 발생하고 자신의 인스턴스를 첫 번째 인자로 그리고 EventArgs 를 두 번째 인자로 전달한다.
이벤트 처리 ; 이벤트 사용하기

어트리뷰트

정의 : 프로그램에 필요한 정보를 제공하는 기능으로, 컴파일타임과 런타임 모두 영향을 미침 어트리뷰트 구문은 대괄호 ([])로 묶어 표현
컴파일러와 구조체 , 클래스 등에 영향을 미치는 범용적인 기능을 제공

대괄호 안에는 지정위치,이름 파라미터 및 명명 파라미터가 들어감

[어트리뷰트명(“positional_parameter”, “named_parameter=value,…)]

[DllImport(Use32.dll”)]

[Obsolete(“메시지를 출력합니다.”)]

[Conditional(“Youngjin.com”)]

어트리뷰트

어트리뷰트는 닷넷이 제공하는 내장 방식과 사용자가 작성한 사용자 정의 방식으로 나뉜다.
닷넷이 제공하는 내장 어트리뷰트는 약 200개 정도 , 모두 Attribute 클래스를 상속받은 sealed 형태의 클래스.

책에서는 DllImport와 Obsolete 어트리뷰트 살펴봄
DllImport 어트리뷰트 ; 사용하기

“User32.dll파일”에 정의된 messagebox

c#에서 내부 메서드 호출하듯이 Win32 API를 사용할수 있다.
DllImport 어트리뷰트 ; 사용하기

Win32 API인 MessageBox 함수 사용법은 다음과 같다.

int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);

Obsolete 어트리뷰트 ; 사용하기

정의 : “폐물이 된, 쓸모없는” . 특정 메서드나 속성을 쓰지 말도록 유도
프로그램의 업그레이드 버전을 작성할 때 기존에 있던 특정 기능을 사용하지못하게 경고하는 용도로 사용된다
summary

델리게이트는 c/c++의 함수 포인터 개념이며
이벤트는 특정 사건을 처리하는 방법
델레게이트 호출 방법과 이벤트 처리하는 방법을 정확히 이해하고 있어야 하겠다.

C# : 다중 상속의 폐해 등과 같이 복잡한 문제점은 제거. 실용성을 중시. .NET Framework의 클래스 라이브러리딜이 이미 C#으로 작성되어 있음

C# 2.0의 주요 특징
-Generic : 더 많은 코드 재활용성과 컬렉션 클랫의 성능 향상을 꾀하기 위해 추가. 매개 변수에 의해 구분되어지며, 매개 변수는 특정 형식을 갖도록 강제 될 수 있음. 데이터 자장과 처리에 있어서 상당한 속도 향상.
-Iterators : Foreach 루프에 의해 컬렉션의 내용을 어떻게 반복하여 접근하는가를 쉽게 지시
-Patial Type : 여러개의 다른 소스파일을 나누어서 클래스를 저장. 시스템이 생성한 코드와 개발자가 작성한 소스 코드를 분리하여 작성 할 수 있음.
-익명 메서드 : 코드 조각을 인자로 전달하는 것이 가능. Delegate가 필요한 곳이면 메서드를 정의할 필요 없이 코드를 사용 가능.

컬렉션 : 저장 공간의 제약을 반지 않고 데이터를 저장, 다양한 데이터 타입의 데이터를 저장할 수 있음.
-값 타입 : 박싱, 언박싱
-참조 타입 : 상위 캐스팅, 하위 캐스팅
*값 타입을 컬렉션 개체에 저장하기 위해서 참조 타입으로의 박싱이 발생하게 되고, 컬렉션 개체에 저장된 데이터를 리턴 받기 위해서는 언박싱이 발생, 개체를 컬렉션에 저장하기 위해서는 부모 클래스의 형태로 상위 캐스팅이 발생, 저장된 데이터를 리턴 받기 위해서는 하위 클래스로 하위 캐스팅을 해야함.

Generics : 동적으로 저장 공간의 사이즈를 늘려 데이터를 저장하는 기능과 동일한 데이터 타입을 저장하는 특징.
-명확한 타입 지정을 통한 컴파일 시의 에러 체크 및 런타임 시의 에러 방지
-불필요한 박싱, 언박싱 방지를 통한 성능 향상
-상위 캐스팅, 하위 캐스팅 방지를 통한 성능 향상
-System.Collections.Generics 네임스페이스 사용을 통한 편이성 제공
*'로직'과 '로직에 의해 다뤄지는 개체'를 명확하게 구분할 수 있음. 유연성에 있어서 선택의 폭이 상당히 넓어졌다고 할 수 있음.
예) Stack<int> store = new Stack<int>(); : 안에 명시하는 데이터 타입에 의해서 현재 Stack 개체에 저장되는 데이터의 타입이 결정.

**readOnly 한정자
-선언의 일부로 대입 또는 동일한 생성자에서 대입하는 경우에만 선언

Generics의 제약 조건
-Generics코드는 클라이언트가 사용하는 특정 형식과 호환되지 않는 Generics 형식 매개 변수의 메서드, 속성 또는 맴버를 사용할 수 있음.
-결과적으로 형식 안전성을 떨어뜨릴 수 있기 때문에 허용될 수 없음.

제약 조건 | 설명
where T : struct | 형식 매개 변수는 Value Type
where T : class | 형식 매개 변수는 Reference Type
where T : new() | 매개 변수를 지니고 있지 않는 Default 생성자를 지니고 있어야 함.
where T : <base class name> | <base class name>에 해당 하는 클래스를 상속받아야 함.
where T : <interface name> | <interface name>에 해당하는 인터페이스를 구현하고 있어야함
**where 키워드로 제약 조건을 정의, 컴파일러에게 형식 매개 변수가 지니고 있는 제약 조건을 알려줌

Dictionaries : Key와 Value의 쌍으로 데이터를 저장할 수 있는 컬렉션
-Dictionary의 경우는 object형태의 Key 값과 value 값을 저장할 수는 있지만 Key 값의 경우는 간단하고 찾기 빠른 형태의 데이터 타입을 사용하는 경우가 일반적
예)
using System;
using System.Collections.Generic;

namespace GenericDictionary
{
    public class Program
    {
        static void Main()
        {
            Dictionary<string, string> dictionary = new Dictionary<string, string>();
            dictionary.Add("01", "Son");
            dictionary.Add("02", "johnharu");
            dictionary.Add("03", "Lee");
            dictionary.Add("04", "Hong");

            Console.WriteLine("dictionary[\"01\"]:{0}", dictionary["01"]);
        }
    }
}

Iterators
-for, foreach의 단점 : 사용자가 직접 정의하는 컬렉션의 경우 foreach 문을 사용하기 위해서는 IEnumerable 인터페이스를 상속받아 GetEnumerator 메소드를 구현해야 하며, Enumerator는 IEnumerator 인터페이스를 상속 받아 관련 메서드를 구현해 주어야 하는 코드상의 불편함이 있음.
-Iterator : foreach문에서 사용되어 지정된 범위만큼을 반복하면서 지속적으로 결과를 리턴하는 코드 블록을 일컫는 말
-IEnumerable을 상속 받아 구현
-기존의 복잡한 형태의 코드를 간결화 하기 위해 새로운 키워드로 yield return 사용

Anonymous Methods
-메서드를 통해 처리하는 내용을 인라인의 형태로 처리하는 방법을 제공
-델리게이트를 통해 메서드를 호출하는 경우에는 호출할 수 있는 메서드의 타입을 델리게이트를 생성하면서 선언-이벤트 발생하였을 경우에 델리게이트를 통해 선언도니 메서드를 호출하여 원하는 작업을 처리하는 방식의 이벤트 기반 프로그램

델리게이트
-한 번의 호출로 하나의 메서드나 여러 개의 메서드를 동시에 호출 할 수 있음
-대부분의 메서드는 완벽한 형태를 띄고 있는 모습이 일반적.
-특정 클래스의 멤버로서 선언
-저장 공간에 자리 잡고 있는 상태
*이런 경우가 아닌 델리게이트의 경우 특정 클래스의 멤버로 선언하여 굳이 개체를 생성하여 호출할 필요 없이 메서드를 통해 처리하고자 하는 작업을 익명 메서드의 형태로 델리게이트를 통해 호출 가능

Nullable 타입
-.Net Framework CTS(Common Type System)에 정의된 데이터 타입에는 값 타입(Value Type)과 참조 타입(Reference Type)이 있음. 두 타입의 다양한 차이점 중에 NULL 값을 설정할 수 있는지의 여부는 두 데이터 타입을 결정짓는 하나의 기준이 됨. 참조 타입의 경우는 널 값을 설정하여 개체 생성을 나중으로 미뤄둘 수 있지만, 값 타입의 경우는 초기화를 통한 데이터의 할당이 이루어져야 함.
-참조 타입이 아닌 값 타입에도 NULL 값을 저장할 수 있도록 C# 2.0에 새롭게 추가된 개념이 Nullable 타입.
-값 타입이 지닐 수 있는 값의 범위에 Null 값이 하나 추가된 개념.