반응형
소프트웨어가 정확히 무엇인가?"와 같은 존재에 대한 질문에는 즉시 답할 수가 없습니다.
다음과 같은 상황을 고려해 보십시오. 여행중에 기념품 가게에서 친구나 가족에게 줄 선물을 고르고 있다고 가정합니다. 이런 경우 판매원은 보통 "처음 방문하신 겁니까? 출장으로 오신 겁니까 아니면 휴가로 오신 겁니까?" 같은 질문을 할 것입니다.
만약 여러분이 소프트웨어와 관련된 일을 하고 있고 휴가 중이 아니라면 위에서 언급한 존재에 대한 질문에 직면하게 됩니다.
그렇다면 정확히 소프트웨어는 무엇에 관한 것인가요?
특히 여러분이 소프트웨어와 직접적인 연관이 없이 그저 휴가를 즐기는 중이라면 이러한 존재에 대한 질문에 답하는 것은 쉽지가 않습니다.
필자는 나름대로 간단하게 고찰해보았습니다. 첫째, 소프트웨어는 컴퓨터와 관련이 있습니다. 또한 소프트웨어는 발전의 산물입니다. 확실히 소프트웨어는 데이터와 관련이 있고, 특히 데이터 저장소 및 조작에 관련이 있습니다.
그렇다면 최근 몇 년동안 데이터 저장소 및 사용에 대해 어떤 종류의 소프트웨어가 발전했는지에 대한 의문이 생깁니다. 따라서 OLE DB 고찰 및 .NET 관점에서 OLE DB의 발전에 대해 살펴보겠습니다.
소프트웨어의 발전 과정
=====================
역사적으로 보면 ODBC는 응용 프로그램이 데이터베이스를 일정한 방식으로 액세스를 하는 최초의 시도였습니다. 소프트웨어의 관점에서 ODBC는 특정한 요구에 부합하기 위해 설계되었습니다. 그리고 정보 기술 발전사에 새로운 장을 열었습니다.
ODBC는 내부 정보, 언어, 테이블 조직 등에 관계없이 데이터베이스를 액세스하는 공통의 추상적인 API를 제공했습니다. 시간이 지남에 따라 새로운 방식으로 데이터 기반 응용 프로그램을 설계하고 구축하는 상황에 ODBC는 부적합하게 되었습니다.
치열한 소프트웨어 경쟁속에서 살아남기 위한 일환으로 ODBC는 다른 이름, 다른 프로그래밍 모델 및 획기적인 기능을 적용하여 위기를 극복했습니다. 그리고 그 다음 OLE DB라는 새로운 기능을 토대로 개방형 데이터베이스 연결을 제공했습니다.
OLE DB는 Microsoft UDA(Universal Data Access) 전략의 이론적인 개념을 구체화한 프로그래밍 인터페이스 모델입니다. UDA(범용 데이터 액세스)는 단일 COM 기반 프로그래밍 인터페이스를 사용하여 관계형, 비관계형, 계층형 등과 같은 모든 유형의 데이터를 액세스할 수 있는 기능을 제공합니다.
구성 요소 기술로 설계되었기 때문에 OLE DB는 여러 계층 구조 모델 기능을 제공합니다. COM 브리지의 한쪽에는 데이터를 보유하는 서버 구성 요소가 있고, 다른 한쪽에는 데이터를 연결하고 요청하는 클라이언트 구성 요소가 있습니다. 전자를 OLE DB 데이터 공급자라고 하고 후자를 OLE DB 소비자라고 합니다.
소비자 및 공급자 모두 COM 개체이므로 COM 인터페이스를 통해 서로 통신할 수 있습니다. COM 기반 통신은 DataSource, Session, Command 및 Rowset과 같은 추상 개체에서 수행되는 작업입니다. 소비자가 DataSource 연결하여 Session을 열고 Command를 수행하면 Rowset 데이터를 가져올 수 있습니다.
ODBC는 UDA 및 OLE DB 기능을 도입하여 결합되었기 때문에 관계형, 비관계형 또는 계층형에 관계없이 모든 엔터프라이즈 데이터를 단일 관계형 테이블처럼 처리할 수 있습니다.
OLE DB 모델
===========
데이터 액세스에 관해서라면 다음과 같은 두 가지 기본 선택이 있습니다. 그 중 하나는 UDA 처럼 데이터 액세스 전략을 범용화하는 것이고, 다른 하나는 데이터 구조에 알맞게 범용화를 적용하는 것입니다. 따라서 현재 데이터 저장소에서 각 데이터를 광범위하게 포함할 수 있는 단일 데이터베이스 서버로 이동해야 합니다.
OLE DB를 이용하면 클라이언트와 모든 결합을 시도할 수 있습니다. 클라이언트에 대해 모든 형식의 정보를 조작할 수 있는 더 강력하고 획기적인 DBMS로 Scaling Up(하드웨어 차원의 확장)을 수행해야 합니다.
OLE DB는 ODBC보다 물리적 데이터 구조에서 매우 독립적입니다. 또한 엄밀히 말해서 SQL 기반이 아닙니다. OLE DB 명령은 SQL 구문 및 그 외 다른 구문일 수 있습니다. 일반적으로 OLE DB 명령은 대상 공급자가 인식할 수 있는 구문에 따라 쓰여진 텍스트 문자열입니다.
ODBC와 같이 OLE DB도 중간 계층 모듈에서 데이터 액세스의 성능을 최대화하기 위해 C++로 설계되었습니다. 이와 같은 이유로 OLE DB는 Visual Basic？ 또는 ASP에서 직접 사용할 수 없습니다.
수 많은 분산 시스템은 구성 요소를 만들기 위해 Visual Basic을 사용했습니다. 이것이 Microsoft가 ADO(ActiveX？ Data Objects) 라이브러리를 소개하게 된 이유입니다.
ADO는 원시 OLE DB SDK보다 다양한 프로그래밍 인터페이스를 가지고 있습니다. C++ 응용 프로그램에서 ADO를 사용할 수 있는 것은 확실하지만 OLE DB 호출은 ADO 코드에 비해 더 적은 코드 계층을 통과하며 보다 직접적인 방식으로 이동합니다.
ADO는 OLE DB 위에 설계되었지만 원시 OLE DB 인터페이스에 대한 호출과 ADO 런타임을 통해 실행된 호출은 다른 상대적 속도를 갖습니다. 이러한 수행은 일종의 언어 기반 문제를 발생시킵니다. 그렇다면 OLE DB의 고성능 수준 C++ 또는 Visual Basic 구성 요소의 더 쉽고 일반적인 ADO 모델 중 어느것이 더 나은 권장 사항일까요?
공급자 및 소비자 외에 OLE DB 모델은 제3요소인 OLE DB 서비스를 포함하고 있습니다. 서비스는 소비자에게 반환되는 Rowset을 처리하는 COM 구성 요소로서 소비자와 공급자 간의 모든 소통량을 모니터하는 후크처럼 작동합니다. ADO는 데이터 모양, 지속성 및 연결이 끊긴 레코드 집합과 같은 확장된 기능을 추가하기 위해 OLE DB 서비스를 전적으로 이용합니다.
분산 COM 기반 응용 프로그램 작성을 지원하기 위한 일환으로 여러 가지 적합한 실습이 특정 분야를 위해 개발되었습니다. 웹 응용 프로그램의 확장성을 향상시키려면 데이터 액세스 연결이 끊긴 모델에 관심을 두어야 합니다.
간단히 말해서 데이터 소비자 및 데이터 공급자는 항상 연결되어 있지 않습니다. 일단 연결이 되면 해당 쿼리 명령을 수행하여 메모리 내부 저장소로 레코드를 가져오고 데이터 원본에서 연결을 끊습니다. 오프라인 상태에서 레코드 작업을 하고 있는 경우 필요하면 나중에 다시 연결하고 변경 내용을 제출할 수 있습니다. 이러한 모델은 일반인 대상이 아닙니다. 확장성 증대 및 전체적인 성능면에서 매우 중요합니다.
데이터 연결을 끊을 수 있는 클라이언트측 커서 서비스를 통해 ADO 레코드 집합을 적용하기 위해 수 많은 시스템이 변환되었습니다. OLE DB는 특히 상호 작용 모델 개념을 포함하고 있지 않기 때문에 ADO는 중간 OLE DB 서비스를 통해 확장됩니다.
기본 제공된 아키텍처의 융통성을 이용하여 OLE DB는 연결이 끊긴 상태에서도 작업을 수행할 수 있습니다. 그렇지만 가장 좋은 작업 방식은 아닙니다. 이러한 구현의 또 다른 미묘한 한계는 ADO 레코드 집합이 모든 작업을 항상 순조롭게 수행할 수 없는 너무 많은 것에 의존한다는 것입니다. 디스크에서 조작하거나 로드할 경우, 연결되거나 연결이 끊긴 상태에서 또는 XML을 사용하거나 사용하지 않고 작업할 때 이와 같은 개체를 어떻게 신속하게 처리할 수 있을까요?
또한 ADO 기능이 원시 OLE DB SDK와 완전히 다르다는 것을 고려하면 OLE DB에는 상당한 일관성의 결여가 불가피합니다.
따라서 ADO.NET은 데이터 액세스 기술 발전 과정의 다음 단계라고 할 수 있습니다. 이름에서도 알 수 있듯이 겉보기에 ADO.NET은 ADO의 계승자입니다. .NET에서 OLE DB에 대해서는 어떻게 생각합니까?
.NET 관리 공급자
=================
시대를 초월한 다윈의 진화론 법칙에 따라 이제 OLE DB 기술은 새 사용자 요구에 부응해야 하는 단계로 이동해야 할 시점에 있습니다. .NET에서 웹 응용 프로그램은 주로 연결이 끊긴 응용 프로그램으로 데이터를 관리하기 위해 새롭게 설계된 임의 도구를 사용할 수 있습니다.
.NET 프레임워크를 사용하여 데이터에 대한 클래스 작업을 할 수 있습니다. 특히 ADO.NET 및 XML 이름 공간과 같은 클래스는 수집, 읽기 및 쓰기를 제공합니다. ADO.NET 및 XML 하위 시스템은 단일 언어 중립 방식으로 데이터를 가져오고 설정할 수 있도록 ADO 및 OLE DB SDK를 교체합니다.
ADO.NET 클래스는 ADO의 데이터베이스 중심 모델과는 반대로 완전한 데이터 중심 설계이기 때문에 ADO 보다 많이 데이터 원본을 추상화합니다.
OLE DB 공급자의 .NET 사본을 관리 공급자라고 합니다. 다음 그림은 공급자의 역할을 설명한 것입니다.
그림 1. 관리 공급자의 아키텍처 다이어그램
OLE DB에는 상호 작용하는 두 개의 계층인 관리 소비자 계층과 관리 공급자 계층이 있습니다. 따라서 데이터를 조작하기 위해 .NET 응용 프로그램에서 소비자 모듈 역할을 하는 특정 클래스나 구성 요소를 찾을 필요가 없습니다.
.NET 응용 프로그램은 원시 프레임워크에서 단지 DataSet 또는DataReader 개체를 사용하며 곧 바로 "관리" 데이터 소비자 역할을 수행합니다. 데이터를 물리적으로 가져오려면 DataSetCommand 및 DBCommand에서 상속받은 특수 클래스의 인스턴스를 사용합니다. 이 클래스는 데이터 원본에 대한 연결을 나타냅니다.
제공된 공급자를 이용하기 위해 일반적인 개체를 사용하는 대신에, 제공된 공급자를 처리하는 방법을 이미 알고 있는 파생된 클래스를 사용합니다. SQLDataSetCommand는 SQL Server 데이터베이스를 처리하고 ADODataSetCommand는 모든 기존 OLE DB 공급자를 포장합니다.
따라서 DataSetCommand와 같은 클래스에 의해 관리 공급자의 역할은 없어지게 됩니다. 프로그래머는 이와 같은 클래스의 역할 수행을 인식할 수 없으며 알 필요도 없습니다. 단지 클래스를 사용하고 속성만 설정하면 됩니다.
위의 그림에서 관리 공급자 계층은 상호 작용 모델을 사용하며, 이 모델은 ODBC 및 OLE DB에서 사용한 모델과 거의 비슷합니다. 소비자 명령 클래스는 데이터 원본을 포장하는 특정 구성 요소를 대상으로 하기 때문에 데이터 원본 행에 대해 읽기/쓰기를 수행하는 해당 프로토콜을 알고 있습니다. 그리고 .NET 클래스가 처리할 방법을 완전히 알고 있는 형식으로 결과를 반환합니다.
이해를 돕기 위해서 OLE DB 및 .NET에서 데이터 검색을 할 때 수행되는 요소를 검토해 봅시다.
대상 공급자를 OLE DB의 COM progID로 확인하고 .NET에서는 접근자 클래스가 그 역할을 수행합니다.
OLE DB 공급자는 주로 IRowset 인터페이스를 제공하는 COM 개체인 행 집합을 항상 반환합니다. ADO을 통해 데이터를 액세스할 경우 행 집합은 보다 다양하고 스크립트가 가능한 개체인 레코드 집합으로 변환됩니다.
.NET 응용 프로그램은 단지 다른 기능을 수행하는 다른 클래스를 사용합니다. DataReader 클래스는 연결된 상태에서 수행하는 간단하고 속도가 빠른 전진 전용 커서로 레코드 단위 기반 액세스를 제공합니다. 그리고 작업을 완료하면 명시적으로 연결을 끊어야 합니다. 반대로 DataSet 개체는 메모리 내부에 있는 연결이 끊긴 테이블의 컬렉션입니다. DataSetCommand 클래스에 의해 채워집니다. DataSet 개체의 컨텐트는 데이터 원본에서 복구된 DataSetCommand 클래스인 XML 스트림을 따릅니다.
다음 컬럼에서는 DataReader 및 DataSet 클래스에 대해 자세히 설명합니다.
데이터는 이진 형식을 사용하여 공급자에서 소비자로 이동합니다. OLE DB를 설치한 경우에는 COM 마샬링을 통해 이동하며 .NET에서는 관리 공급자가 XML 스트림을 반환합니다.
모든 공급자는 공급업체용 소유권으로 SQL에서 일반적으로 사용하는 쿼리 언어를 지원합니다. 이 쿼리 언어를 사용하여 데이터 원본의 업데이트 및 질의를 수행할 수 있습니다.
그러면 OLE DB 데이터 공급자와 .NET 데이터 공급자는 어떤 점이 다릅니까? 추상적으로 보면 두 공급자는 동일한 데이터 액세스 비전을 공유합니다. 그러나 관리 공급자는 더 간단하고 특수화되었기 때문에 다음과 같은 두 가지 이유로 더 나은 성능을 수행합니다. 첫째, 관리 공급자는 데이터를 가져오고 설정하기 위해 COM Interop 브리지를 사용하지 않습니다. 반면 OLE DB 공급자는 COM 구성 요소가 있으므로 이 단계에서는 선택할 사항이 없습니다. 둘째, 관리 공급자는 더 신속하게 행을 가져오고 설정하기 위해 일반적으로 데이터 원본 내부의 공급업체 정보를 사용합니다. 이 점은 또한 OLE DB 공급자가 어떤 기능을 수행하는지 보여주고 있습니다. 그러나 .NET의 OLE DB 공급자에서 사용하는 경우 COM 기반의 특성에 대한 대가를 지불해야 하며 데이터를 .NET 전용 클래스로 변환하기 위해 추가 코드가 필요합니다.
기존 관리 공급자
=================
.NET 프레임워크 베타 1에는 두 가지 관리 공급자가 있습니다. 하나는 SQL Server용(버전 7.0 이상)이고 다른 하나는 OLE DB 공급자를 통해 접근할 수 있는 모든 데이터 원본용입니다.
SQL Server 관리 공급자는 SQLDataReader, SQLDataSetCommand 및 SQLCommand와 같은 특정 클래스 뒤에 숨겨져 있습니다. 이러한 클래스는 저수준 SQL Server 파일 시스템에 직접적인 액세스를 수행합니다. 다음 그림은 이전의 일반 스키마를 SQL Server의 관리 공급자와 매핑한 공급자의 클래스 다이어그램입니다.
그림 2. SQL Server 관리 공급자의 클래스 다이어그램
OLE DB 관리 공급자는 Windows DNA 시스템의 ODBC에 대한 OLE DB 공급자처럼 .NET에서 동일한 역할을 수행합니다. 기본적으로 이전 버전과의 호환성을 포함하고 있으며, 그 실례로 모든 .NET 응용 프로그램은 기존 OLE DB 기반 데이터 원본을 대상으로 수행할 수 있습니다. 다음 그림은 OLE DB 관리 공급자의 클래스 다이어그램입니다.
그림 3. OLE DB 관리 공급자의 클래스 다이어그램
ADOxxx 클래스는 베타 2에서 OleDbxxx로 이름이 변경됩니다.
OLE DB 관리 공급자는 해당 호출자에게 .NET 클래스를 제공하지만 행을 가져오기 위해 지정된 OLE DB 공급자를 사용합니다. .NET 응용 프로그램과 기본 OLE DB 공급자(COM 개체) 간의 통신은 COM Interop 브리지를 통해 이루어집니다.
그리고 .NET에서 이 두 공급자를 통해 SQL Server 7.0 (또는 그 이상 버전) 테이블을 액세스할 수 있습니다. SQL Server의 관리 공급자는 데이터를 요청하기 위해 곧바로 DBMS 파일 시스템으로 이동합니다. 대신에 OLE DB 관리 공급자는 추가 코드 계층이 통과되도록 하는 SQLOLEDB OLE DB 공급자의 서비스에 의존합니다.
SQL Server가 아니라 다른 데이터 원본을 대상으로 하고 있는 경우 OLE DB 관리 공급자를 사용하는 것이 유일한 방법입니다. 이와 같은 동일한 채널을 통해 모든 ODBC 데이터 원본에 접근할 수 있습니다.
OLE DB 관리 공급자는 원시 OLE DB 공급자를 호출하는 COM Interop 브리지 위에 설치된 얇은 래퍼입니다. 호출을 설정하고 종료하는 것 외에 모듈은 나중에 .NET에서 처리할 DataSet 또는 ADODataReader 개체에 반환된 행 집합을 압축합니다.
.NET 코드 수준에서 원시 관리 공급자 또는 OLE DB 공급자를 통해 SQL Server 테이블을 액세스하는 것은 필수적으로 관련된 클래스의 접두사를 변경해야 합니다. 다음은 SQL Server의 코드 예제입니다.
Dim strConn, strCmd As String
strConn = "DATABASE=Northwind;SERVER=localhost;UID=sa;PWD=;"
strCmd = "SELECT * FROM Employees"
Dim oCMD As New SQLDataSetCommand(strCmd, strConn)
Dim oDS As New DataSet
oCMD.FillDataSet(oDS, "EmployeesList")
그리고 다음은 OLE DB 공급자 코드이며 볼드체는 SQL Server의 코드와의 차이점을 표시한 것입니다.
Dim strConn, strCmd As String
strConn = "Provider=SQLOLEDB;"
strConn += "DATABASE=Northwind;SERVER=localhost;UID=sa;PWD=;"
strCmd = "SELECT * FROM Employees"
Dim oCMD As New ADODataSetCommand(strCmd, strConn)
Dim oDS As New DataSet
oCMD.FillDataSet(oDS, "EmployeesList")
위의 두 코드를 보면 알 수 있듯이, 연결 스트링 및 명령 클래스에 대해서만 아주 근소한 차이가 있을 뿐입니다. 클래스 하나 또는 다른 클래스를 적용하여 차이가 나게 구성할 수도 있습니다.
OLE DB의 존재에 대한 질문
========================
.NET 관리 공급자는 데이터 액세스 기술 발전의 다음 단계라고 할 수 있습니다. 그러나 베타 1에는 데이터 원본용 관리 공급자를 작성하기 위한 문서화된 SDK가 없습니다. 베타 2를 기대하면서 OLE DB 및 .NET 에 대한 몇 가지 기본적인 질문을 살펴보겠습니다.
OLE DB를 위해 개발된 코드는 단지 레거시 코드인가? 기업들이 자체 데이터에 대해 공급자를 작성하려고 모든 노력을 하는 이유는 무엇인가?
OLE DB는 사장된 기술이 아닙니다. OLE DB는 여전히 다양한 기능, 범용 및 .NET 독립적 프로그래밍 인터페이스를 위한 기초적인 사양입니다. .NET에만 한정되는 것은 아니지만 잘 지원됩니다.
제공해야 할 사용자 지정 데이터가 있는 경우 .NET 및 관리 공급자의 역할을 무시할 수 없습니다. 그러면 데이터 공급자를 이용할 수 있는 가장 좋은 인터페이스는 무엇인가? 예를 들어 다음 주 월요일 오전 8시에 데이터를 제공하려면 어떻게 계획을 세워야 하는가?
.NET은 개방 표준을 사용하며 전적으로 XML을 기본으로 합니다. 소유권이 있는 경우 텍스트 기반 데이터를 제공하기 위해서는 사용자 지정 스키마 및 XML을 사용하여 게시를 고려할 수 있습니다. .NET에는 래퍼 클래스를 비롯하여 XML 데이터와 수행할 수 있는 많은 기능이 있습니다.
더 복잡한 데이터 저장소인 경우에는 .NET에 바운드되지 않을지도 모르는 더 많은 사용자를 접근해야 하기 때문에 OLE DB 공급자는 여전히 중요합니다. .NET 전용 응용 프로그램을 위해 관리 공급자는 안정적인 성능을 제공합니다. 관리 공급자용 SDK는 아직 출시되지 않았다는 것을 기억하십시오. 그러나 Microsoft는 곧 제공할 것을 약속합니다.
다음 컬럼에 소개할 데이터 공급자에서는 두 가지의 OLE DB 관리자 및 XML의 NET 래퍼 클래스에 대해 설명합니다. 저자의 견해는 COM Interop을 통해 OLE DB 공급자가 래핑된 .NET 클래스를 사용하는 것이 좋지 않다는 것입니다. 동일하면서도 잘 적용되는 원본 코드를 도입하는 것이 낫습니다. 이 경우 "물리적" 코드 재사용의 기능을 사용하려면 관리 C++가 아마 가장 적합한 언어일 것입니다.
OLE DB의 행로
=============
지금부터 약 2년 후에 증명될 다음과 같은 예측을 해봅시다. 결국 OLE DB는 XML의 선구자인 SGML(Standard Generalized Markup Language)과 같은 비교적 나쁜 결말이 될지도 모릅니다.
데이터 교환 기술 분야의 구원자로서 소개된 SGML은 일반인이 사용하기에 너무 어렵고 복잡했기 때문에 완전한 표준이 되지 못했습니다. 사실 SGML의 원리는 간소화되고 특수화된 XML이 소개된 이후에 많은 분야에 적용되었습니다.
저자의 예상으로는 .NET이 곧 업계를 주도할 것이고 OLE DB는 점차 그 중요성을 잃게 되어 사라지게 될 것입니다. 이러한 변화가 실제로 언제 나타날지 모르지만 확신합니다.
사례를 조만간에 소개할 것입니다. 계속 지켜봐 주십시오.
대화 상자: 레거시 코드
=====================
여러분은 아마 또 다른 차원의 시대에 살고 있는지도 모릅니다! 대부분의 경우 6개월 전 또는 후에 쓰여진 기존 ADO 코드로서 레거시 코드를 어떻게 정의할 수 있습니까? 베타 프로그램의 두 번째 단계도 아닌 .NET이라는 기술/플랫폼의 이름으로 어떻게 정의할 수 있습니까?
일상 생활에서도 어떤 활력소가 필요합니다.
현재 많은 DNA 시스템에서 사용되는 ADO 코드로 레거시 코드를 정의할 수 있습니까? 저자의 대답은 여전히 "예, 해야 할 작업입니다."이지만 확실히 당혹스런 답변입니다.
코드에 있어서 "레거시 코드"는 더 이상 플랫폼을 호스트하는 핵심 요소가 될 수 없습니다. 즉, NET의 출현으로 인해 이런 현상이 발생할 것입니다. 물론 .NET에서 기존 코드, 구성 요소 및 응용 프로그램을 통합하는 방식이 있을 것입니다.
.NET은 일종의 비폭력 혁명과 같이 앞으로 몇 년안에 Windows에서 현존하는 모든 소프트웨어의 인스턴스를 흡수할 것입니다. 이것은 대세이며 곧 적응될 것입니다. 앞에서 레거시 코드를 정의한 바와 같이, 코드의 수명에 관계없이 레거시 코드는 원본과 런타임 간의 정렬입니다.
.NET은 Windows 런타임을 변경합니다. COM 및 Windows SDK는 사장되지 않았지만 다른 모델을 기반으로 코드를 작성해야 합니다. 이 새로운 런타임 토대에 관계없이 처리할 수 있는 새 모델이 있습니다. 그리고 이 모델은 차후 Windows 모델이 될 것입니다.
Windows는 사장되지 않았지만 변경될 것입니다. COM도 사장되지 않았지만 .NET 클래스를 적용해야 하며, ADO도 아직 사용되고 있지만 ADO.NET의 .NET 기능이 ADO의 미래입니다.
.NET은 단순히 Windows 6.0이 아니며 ADO.NET은 ADO 3.0으로 명명할 수 있는 차원이 아닙니다. ADO.NET은 완전히 다른 새로운 플랫폼입니다. 그리고 나머지는 모두 다른 플랫폼 또는 통합된 경우 레거시 코드입니다.
레거시 코드는 제한된 수명이 없습니다. .NET이 실제로 출시되는 경우에도 사용자들은 이번 주 또는 6개월 후에 DNA 시스템을 작성하고 있을 것입니다. 하지만 이것이 확실히 잘못되었다고 또는 피해야 한다고 말할 수는 없습니다. 한마디로 시류에 역행한다고 볼 수 있습니다.
============================================
<마이크로소프트>사 자체의 보고서 내용, 땅야땅야님 블로그에서 퍼옴..
다음과 같은 상황을 고려해 보십시오. 여행중에 기념품 가게에서 친구나 가족에게 줄 선물을 고르고 있다고 가정합니다. 이런 경우 판매원은 보통 "처음 방문하신 겁니까? 출장으로 오신 겁니까 아니면 휴가로 오신 겁니까?" 같은 질문을 할 것입니다.
만약 여러분이 소프트웨어와 관련된 일을 하고 있고 휴가 중이 아니라면 위에서 언급한 존재에 대한 질문에 직면하게 됩니다.
그렇다면 정확히 소프트웨어는 무엇에 관한 것인가요?
특히 여러분이 소프트웨어와 직접적인 연관이 없이 그저 휴가를 즐기는 중이라면 이러한 존재에 대한 질문에 답하는 것은 쉽지가 않습니다.
필자는 나름대로 간단하게 고찰해보았습니다. 첫째, 소프트웨어는 컴퓨터와 관련이 있습니다. 또한 소프트웨어는 발전의 산물입니다. 확실히 소프트웨어는 데이터와 관련이 있고, 특히 데이터 저장소 및 조작에 관련이 있습니다.
그렇다면 최근 몇 년동안 데이터 저장소 및 사용에 대해 어떤 종류의 소프트웨어가 발전했는지에 대한 의문이 생깁니다. 따라서 OLE DB 고찰 및 .NET 관점에서 OLE DB의 발전에 대해 살펴보겠습니다.
소프트웨어의 발전 과정
=====================
역사적으로 보면 ODBC는 응용 프로그램이 데이터베이스를 일정한 방식으로 액세스를 하는 최초의 시도였습니다. 소프트웨어의 관점에서 ODBC는 특정한 요구에 부합하기 위해 설계되었습니다. 그리고 정보 기술 발전사에 새로운 장을 열었습니다.
ODBC는 내부 정보, 언어, 테이블 조직 등에 관계없이 데이터베이스를 액세스하는 공통의 추상적인 API를 제공했습니다. 시간이 지남에 따라 새로운 방식으로 데이터 기반 응용 프로그램을 설계하고 구축하는 상황에 ODBC는 부적합하게 되었습니다.
치열한 소프트웨어 경쟁속에서 살아남기 위한 일환으로 ODBC는 다른 이름, 다른 프로그래밍 모델 및 획기적인 기능을 적용하여 위기를 극복했습니다. 그리고 그 다음 OLE DB라는 새로운 기능을 토대로 개방형 데이터베이스 연결을 제공했습니다.
OLE DB는 Microsoft UDA(Universal Data Access) 전략의 이론적인 개념을 구체화한 프로그래밍 인터페이스 모델입니다. UDA(범용 데이터 액세스)는 단일 COM 기반 프로그래밍 인터페이스를 사용하여 관계형, 비관계형, 계층형 등과 같은 모든 유형의 데이터를 액세스할 수 있는 기능을 제공합니다.
구성 요소 기술로 설계되었기 때문에 OLE DB는 여러 계층 구조 모델 기능을 제공합니다. COM 브리지의 한쪽에는 데이터를 보유하는 서버 구성 요소가 있고, 다른 한쪽에는 데이터를 연결하고 요청하는 클라이언트 구성 요소가 있습니다. 전자를 OLE DB 데이터 공급자라고 하고 후자를 OLE DB 소비자라고 합니다.
소비자 및 공급자 모두 COM 개체이므로 COM 인터페이스를 통해 서로 통신할 수 있습니다. COM 기반 통신은 DataSource, Session, Command 및 Rowset과 같은 추상 개체에서 수행되는 작업입니다. 소비자가 DataSource 연결하여 Session을 열고 Command를 수행하면 Rowset 데이터를 가져올 수 있습니다.
ODBC는 UDA 및 OLE DB 기능을 도입하여 결합되었기 때문에 관계형, 비관계형 또는 계층형에 관계없이 모든 엔터프라이즈 데이터를 단일 관계형 테이블처럼 처리할 수 있습니다.
OLE DB 모델
===========
데이터 액세스에 관해서라면 다음과 같은 두 가지 기본 선택이 있습니다. 그 중 하나는 UDA 처럼 데이터 액세스 전략을 범용화하는 것이고, 다른 하나는 데이터 구조에 알맞게 범용화를 적용하는 것입니다. 따라서 현재 데이터 저장소에서 각 데이터를 광범위하게 포함할 수 있는 단일 데이터베이스 서버로 이동해야 합니다.
OLE DB를 이용하면 클라이언트와 모든 결합을 시도할 수 있습니다. 클라이언트에 대해 모든 형식의 정보를 조작할 수 있는 더 강력하고 획기적인 DBMS로 Scaling Up(하드웨어 차원의 확장)을 수행해야 합니다.
OLE DB는 ODBC보다 물리적 데이터 구조에서 매우 독립적입니다. 또한 엄밀히 말해서 SQL 기반이 아닙니다. OLE DB 명령은 SQL 구문 및 그 외 다른 구문일 수 있습니다. 일반적으로 OLE DB 명령은 대상 공급자가 인식할 수 있는 구문에 따라 쓰여진 텍스트 문자열입니다.
ODBC와 같이 OLE DB도 중간 계층 모듈에서 데이터 액세스의 성능을 최대화하기 위해 C++로 설계되었습니다. 이와 같은 이유로 OLE DB는 Visual Basic？ 또는 ASP에서 직접 사용할 수 없습니다.
수 많은 분산 시스템은 구성 요소를 만들기 위해 Visual Basic을 사용했습니다. 이것이 Microsoft가 ADO(ActiveX？ Data Objects) 라이브러리를 소개하게 된 이유입니다.
ADO는 원시 OLE DB SDK보다 다양한 프로그래밍 인터페이스를 가지고 있습니다. C++ 응용 프로그램에서 ADO를 사용할 수 있는 것은 확실하지만 OLE DB 호출은 ADO 코드에 비해 더 적은 코드 계층을 통과하며 보다 직접적인 방식으로 이동합니다.
ADO는 OLE DB 위에 설계되었지만 원시 OLE DB 인터페이스에 대한 호출과 ADO 런타임을 통해 실행된 호출은 다른 상대적 속도를 갖습니다. 이러한 수행은 일종의 언어 기반 문제를 발생시킵니다. 그렇다면 OLE DB의 고성능 수준 C++ 또는 Visual Basic 구성 요소의 더 쉽고 일반적인 ADO 모델 중 어느것이 더 나은 권장 사항일까요?
공급자 및 소비자 외에 OLE DB 모델은 제3요소인 OLE DB 서비스를 포함하고 있습니다. 서비스는 소비자에게 반환되는 Rowset을 처리하는 COM 구성 요소로서 소비자와 공급자 간의 모든 소통량을 모니터하는 후크처럼 작동합니다. ADO는 데이터 모양, 지속성 및 연결이 끊긴 레코드 집합과 같은 확장된 기능을 추가하기 위해 OLE DB 서비스를 전적으로 이용합니다.
분산 COM 기반 응용 프로그램 작성을 지원하기 위한 일환으로 여러 가지 적합한 실습이 특정 분야를 위해 개발되었습니다. 웹 응용 프로그램의 확장성을 향상시키려면 데이터 액세스 연결이 끊긴 모델에 관심을 두어야 합니다.
간단히 말해서 데이터 소비자 및 데이터 공급자는 항상 연결되어 있지 않습니다. 일단 연결이 되면 해당 쿼리 명령을 수행하여 메모리 내부 저장소로 레코드를 가져오고 데이터 원본에서 연결을 끊습니다. 오프라인 상태에서 레코드 작업을 하고 있는 경우 필요하면 나중에 다시 연결하고 변경 내용을 제출할 수 있습니다. 이러한 모델은 일반인 대상이 아닙니다. 확장성 증대 및 전체적인 성능면에서 매우 중요합니다.
데이터 연결을 끊을 수 있는 클라이언트측 커서 서비스를 통해 ADO 레코드 집합을 적용하기 위해 수 많은 시스템이 변환되었습니다. OLE DB는 특히 상호 작용 모델 개념을 포함하고 있지 않기 때문에 ADO는 중간 OLE DB 서비스를 통해 확장됩니다.
기본 제공된 아키텍처의 융통성을 이용하여 OLE DB는 연결이 끊긴 상태에서도 작업을 수행할 수 있습니다. 그렇지만 가장 좋은 작업 방식은 아닙니다. 이러한 구현의 또 다른 미묘한 한계는 ADO 레코드 집합이 모든 작업을 항상 순조롭게 수행할 수 없는 너무 많은 것에 의존한다는 것입니다. 디스크에서 조작하거나 로드할 경우, 연결되거나 연결이 끊긴 상태에서 또는 XML을 사용하거나 사용하지 않고 작업할 때 이와 같은 개체를 어떻게 신속하게 처리할 수 있을까요?
또한 ADO 기능이 원시 OLE DB SDK와 완전히 다르다는 것을 고려하면 OLE DB에는 상당한 일관성의 결여가 불가피합니다.
따라서 ADO.NET은 데이터 액세스 기술 발전 과정의 다음 단계라고 할 수 있습니다. 이름에서도 알 수 있듯이 겉보기에 ADO.NET은 ADO의 계승자입니다. .NET에서 OLE DB에 대해서는 어떻게 생각합니까?
.NET 관리 공급자
=================
시대를 초월한 다윈의 진화론 법칙에 따라 이제 OLE DB 기술은 새 사용자 요구에 부응해야 하는 단계로 이동해야 할 시점에 있습니다. .NET에서 웹 응용 프로그램은 주로 연결이 끊긴 응용 프로그램으로 데이터를 관리하기 위해 새롭게 설계된 임의 도구를 사용할 수 있습니다.
.NET 프레임워크를 사용하여 데이터에 대한 클래스 작업을 할 수 있습니다. 특히 ADO.NET 및 XML 이름 공간과 같은 클래스는 수집, 읽기 및 쓰기를 제공합니다. ADO.NET 및 XML 하위 시스템은 단일 언어 중립 방식으로 데이터를 가져오고 설정할 수 있도록 ADO 및 OLE DB SDK를 교체합니다.
ADO.NET 클래스는 ADO의 데이터베이스 중심 모델과는 반대로 완전한 데이터 중심 설계이기 때문에 ADO 보다 많이 데이터 원본을 추상화합니다.
OLE DB 공급자의 .NET 사본을 관리 공급자라고 합니다. 다음 그림은 공급자의 역할을 설명한 것입니다.
그림 1. 관리 공급자의 아키텍처 다이어그램
OLE DB에는 상호 작용하는 두 개의 계층인 관리 소비자 계층과 관리 공급자 계층이 있습니다. 따라서 데이터를 조작하기 위해 .NET 응용 프로그램에서 소비자 모듈 역할을 하는 특정 클래스나 구성 요소를 찾을 필요가 없습니다.
.NET 응용 프로그램은 원시 프레임워크에서 단지 DataSet 또는DataReader 개체를 사용하며 곧 바로 "관리" 데이터 소비자 역할을 수행합니다. 데이터를 물리적으로 가져오려면 DataSetCommand 및 DBCommand에서 상속받은 특수 클래스의 인스턴스를 사용합니다. 이 클래스는 데이터 원본에 대한 연결을 나타냅니다.
제공된 공급자를 이용하기 위해 일반적인 개체를 사용하는 대신에, 제공된 공급자를 처리하는 방법을 이미 알고 있는 파생된 클래스를 사용합니다. SQLDataSetCommand는 SQL Server 데이터베이스를 처리하고 ADODataSetCommand는 모든 기존 OLE DB 공급자를 포장합니다.
따라서 DataSetCommand와 같은 클래스에 의해 관리 공급자의 역할은 없어지게 됩니다. 프로그래머는 이와 같은 클래스의 역할 수행을 인식할 수 없으며 알 필요도 없습니다. 단지 클래스를 사용하고 속성만 설정하면 됩니다.
위의 그림에서 관리 공급자 계층은 상호 작용 모델을 사용하며, 이 모델은 ODBC 및 OLE DB에서 사용한 모델과 거의 비슷합니다. 소비자 명령 클래스는 데이터 원본을 포장하는 특정 구성 요소를 대상으로 하기 때문에 데이터 원본 행에 대해 읽기/쓰기를 수행하는 해당 프로토콜을 알고 있습니다. 그리고 .NET 클래스가 처리할 방법을 완전히 알고 있는 형식으로 결과를 반환합니다.
이해를 돕기 위해서 OLE DB 및 .NET에서 데이터 검색을 할 때 수행되는 요소를 검토해 봅시다.
대상 공급자를 OLE DB의 COM progID로 확인하고 .NET에서는 접근자 클래스가 그 역할을 수행합니다.
OLE DB 공급자는 주로 IRowset 인터페이스를 제공하는 COM 개체인 행 집합을 항상 반환합니다. ADO을 통해 데이터를 액세스할 경우 행 집합은 보다 다양하고 스크립트가 가능한 개체인 레코드 집합으로 변환됩니다.
.NET 응용 프로그램은 단지 다른 기능을 수행하는 다른 클래스를 사용합니다. DataReader 클래스는 연결된 상태에서 수행하는 간단하고 속도가 빠른 전진 전용 커서로 레코드 단위 기반 액세스를 제공합니다. 그리고 작업을 완료하면 명시적으로 연결을 끊어야 합니다. 반대로 DataSet 개체는 메모리 내부에 있는 연결이 끊긴 테이블의 컬렉션입니다. DataSetCommand 클래스에 의해 채워집니다. DataSet 개체의 컨텐트는 데이터 원본에서 복구된 DataSetCommand 클래스인 XML 스트림을 따릅니다.
다음 컬럼에서는 DataReader 및 DataSet 클래스에 대해 자세히 설명합니다.
데이터는 이진 형식을 사용하여 공급자에서 소비자로 이동합니다. OLE DB를 설치한 경우에는 COM 마샬링을 통해 이동하며 .NET에서는 관리 공급자가 XML 스트림을 반환합니다.
모든 공급자는 공급업체용 소유권으로 SQL에서 일반적으로 사용하는 쿼리 언어를 지원합니다. 이 쿼리 언어를 사용하여 데이터 원본의 업데이트 및 질의를 수행할 수 있습니다.
그러면 OLE DB 데이터 공급자와 .NET 데이터 공급자는 어떤 점이 다릅니까? 추상적으로 보면 두 공급자는 동일한 데이터 액세스 비전을 공유합니다. 그러나 관리 공급자는 더 간단하고 특수화되었기 때문에 다음과 같은 두 가지 이유로 더 나은 성능을 수행합니다. 첫째, 관리 공급자는 데이터를 가져오고 설정하기 위해 COM Interop 브리지를 사용하지 않습니다. 반면 OLE DB 공급자는 COM 구성 요소가 있으므로 이 단계에서는 선택할 사항이 없습니다. 둘째, 관리 공급자는 더 신속하게 행을 가져오고 설정하기 위해 일반적으로 데이터 원본 내부의 공급업체 정보를 사용합니다. 이 점은 또한 OLE DB 공급자가 어떤 기능을 수행하는지 보여주고 있습니다. 그러나 .NET의 OLE DB 공급자에서 사용하는 경우 COM 기반의 특성에 대한 대가를 지불해야 하며 데이터를 .NET 전용 클래스로 변환하기 위해 추가 코드가 필요합니다.
기존 관리 공급자
=================
.NET 프레임워크 베타 1에는 두 가지 관리 공급자가 있습니다. 하나는 SQL Server용(버전 7.0 이상)이고 다른 하나는 OLE DB 공급자를 통해 접근할 수 있는 모든 데이터 원본용입니다.
SQL Server 관리 공급자는 SQLDataReader, SQLDataSetCommand 및 SQLCommand와 같은 특정 클래스 뒤에 숨겨져 있습니다. 이러한 클래스는 저수준 SQL Server 파일 시스템에 직접적인 액세스를 수행합니다. 다음 그림은 이전의 일반 스키마를 SQL Server의 관리 공급자와 매핑한 공급자의 클래스 다이어그램입니다.
그림 2. SQL Server 관리 공급자의 클래스 다이어그램
OLE DB 관리 공급자는 Windows DNA 시스템의 ODBC에 대한 OLE DB 공급자처럼 .NET에서 동일한 역할을 수행합니다. 기본적으로 이전 버전과의 호환성을 포함하고 있으며, 그 실례로 모든 .NET 응용 프로그램은 기존 OLE DB 기반 데이터 원본을 대상으로 수행할 수 있습니다. 다음 그림은 OLE DB 관리 공급자의 클래스 다이어그램입니다.
그림 3. OLE DB 관리 공급자의 클래스 다이어그램
ADOxxx 클래스는 베타 2에서 OleDbxxx로 이름이 변경됩니다.
OLE DB 관리 공급자는 해당 호출자에게 .NET 클래스를 제공하지만 행을 가져오기 위해 지정된 OLE DB 공급자를 사용합니다. .NET 응용 프로그램과 기본 OLE DB 공급자(COM 개체) 간의 통신은 COM Interop 브리지를 통해 이루어집니다.
그리고 .NET에서 이 두 공급자를 통해 SQL Server 7.0 (또는 그 이상 버전) 테이블을 액세스할 수 있습니다. SQL Server의 관리 공급자는 데이터를 요청하기 위해 곧바로 DBMS 파일 시스템으로 이동합니다. 대신에 OLE DB 관리 공급자는 추가 코드 계층이 통과되도록 하는 SQLOLEDB OLE DB 공급자의 서비스에 의존합니다.
SQL Server가 아니라 다른 데이터 원본을 대상으로 하고 있는 경우 OLE DB 관리 공급자를 사용하는 것이 유일한 방법입니다. 이와 같은 동일한 채널을 통해 모든 ODBC 데이터 원본에 접근할 수 있습니다.
OLE DB 관리 공급자는 원시 OLE DB 공급자를 호출하는 COM Interop 브리지 위에 설치된 얇은 래퍼입니다. 호출을 설정하고 종료하는 것 외에 모듈은 나중에 .NET에서 처리할 DataSet 또는 ADODataReader 개체에 반환된 행 집합을 압축합니다.
.NET 코드 수준에서 원시 관리 공급자 또는 OLE DB 공급자를 통해 SQL Server 테이블을 액세스하는 것은 필수적으로 관련된 클래스의 접두사를 변경해야 합니다. 다음은 SQL Server의 코드 예제입니다.
Dim strConn, strCmd As String
strConn = "DATABASE=Northwind;SERVER=localhost;UID=sa;PWD=;"
strCmd = "SELECT * FROM Employees"
Dim oCMD As New SQLDataSetCommand(strCmd, strConn)
Dim oDS As New DataSet
oCMD.FillDataSet(oDS, "EmployeesList")
그리고 다음은 OLE DB 공급자 코드이며 볼드체는 SQL Server의 코드와의 차이점을 표시한 것입니다.
Dim strConn, strCmd As String
strConn = "Provider=SQLOLEDB;"
strConn += "DATABASE=Northwind;SERVER=localhost;UID=sa;PWD=;"
strCmd = "SELECT * FROM Employees"
Dim oCMD As New ADODataSetCommand(strCmd, strConn)
Dim oDS As New DataSet
oCMD.FillDataSet(oDS, "EmployeesList")
위의 두 코드를 보면 알 수 있듯이, 연결 스트링 및 명령 클래스에 대해서만 아주 근소한 차이가 있을 뿐입니다. 클래스 하나 또는 다른 클래스를 적용하여 차이가 나게 구성할 수도 있습니다.
OLE DB의 존재에 대한 질문
========================
.NET 관리 공급자는 데이터 액세스 기술 발전의 다음 단계라고 할 수 있습니다. 그러나 베타 1에는 데이터 원본용 관리 공급자를 작성하기 위한 문서화된 SDK가 없습니다. 베타 2를 기대하면서 OLE DB 및 .NET 에 대한 몇 가지 기본적인 질문을 살펴보겠습니다.
OLE DB를 위해 개발된 코드는 단지 레거시 코드인가? 기업들이 자체 데이터에 대해 공급자를 작성하려고 모든 노력을 하는 이유는 무엇인가?
OLE DB는 사장된 기술이 아닙니다. OLE DB는 여전히 다양한 기능, 범용 및 .NET 독립적 프로그래밍 인터페이스를 위한 기초적인 사양입니다. .NET에만 한정되는 것은 아니지만 잘 지원됩니다.
제공해야 할 사용자 지정 데이터가 있는 경우 .NET 및 관리 공급자의 역할을 무시할 수 없습니다. 그러면 데이터 공급자를 이용할 수 있는 가장 좋은 인터페이스는 무엇인가? 예를 들어 다음 주 월요일 오전 8시에 데이터를 제공하려면 어떻게 계획을 세워야 하는가?
.NET은 개방 표준을 사용하며 전적으로 XML을 기본으로 합니다. 소유권이 있는 경우 텍스트 기반 데이터를 제공하기 위해서는 사용자 지정 스키마 및 XML을 사용하여 게시를 고려할 수 있습니다. .NET에는 래퍼 클래스를 비롯하여 XML 데이터와 수행할 수 있는 많은 기능이 있습니다.
더 복잡한 데이터 저장소인 경우에는 .NET에 바운드되지 않을지도 모르는 더 많은 사용자를 접근해야 하기 때문에 OLE DB 공급자는 여전히 중요합니다. .NET 전용 응용 프로그램을 위해 관리 공급자는 안정적인 성능을 제공합니다. 관리 공급자용 SDK는 아직 출시되지 않았다는 것을 기억하십시오. 그러나 Microsoft는 곧 제공할 것을 약속합니다.
다음 컬럼에 소개할 데이터 공급자에서는 두 가지의 OLE DB 관리자 및 XML의 NET 래퍼 클래스에 대해 설명합니다. 저자의 견해는 COM Interop을 통해 OLE DB 공급자가 래핑된 .NET 클래스를 사용하는 것이 좋지 않다는 것입니다. 동일하면서도 잘 적용되는 원본 코드를 도입하는 것이 낫습니다. 이 경우 "물리적" 코드 재사용의 기능을 사용하려면 관리 C++가 아마 가장 적합한 언어일 것입니다.
OLE DB의 행로
=============
지금부터 약 2년 후에 증명될 다음과 같은 예측을 해봅시다. 결국 OLE DB는 XML의 선구자인 SGML(Standard Generalized Markup Language)과 같은 비교적 나쁜 결말이 될지도 모릅니다.
데이터 교환 기술 분야의 구원자로서 소개된 SGML은 일반인이 사용하기에 너무 어렵고 복잡했기 때문에 완전한 표준이 되지 못했습니다. 사실 SGML의 원리는 간소화되고 특수화된 XML이 소개된 이후에 많은 분야에 적용되었습니다.
저자의 예상으로는 .NET이 곧 업계를 주도할 것이고 OLE DB는 점차 그 중요성을 잃게 되어 사라지게 될 것입니다. 이러한 변화가 실제로 언제 나타날지 모르지만 확신합니다.
사례를 조만간에 소개할 것입니다. 계속 지켜봐 주십시오.
대화 상자: 레거시 코드
=====================
여러분은 아마 또 다른 차원의 시대에 살고 있는지도 모릅니다! 대부분의 경우 6개월 전 또는 후에 쓰여진 기존 ADO 코드로서 레거시 코드를 어떻게 정의할 수 있습니까? 베타 프로그램의 두 번째 단계도 아닌 .NET이라는 기술/플랫폼의 이름으로 어떻게 정의할 수 있습니까?
일상 생활에서도 어떤 활력소가 필요합니다.
현재 많은 DNA 시스템에서 사용되는 ADO 코드로 레거시 코드를 정의할 수 있습니까? 저자의 대답은 여전히 "예, 해야 할 작업입니다."이지만 확실히 당혹스런 답변입니다.
코드에 있어서 "레거시 코드"는 더 이상 플랫폼을 호스트하는 핵심 요소가 될 수 없습니다. 즉, NET의 출현으로 인해 이런 현상이 발생할 것입니다. 물론 .NET에서 기존 코드, 구성 요소 및 응용 프로그램을 통합하는 방식이 있을 것입니다.
.NET은 일종의 비폭력 혁명과 같이 앞으로 몇 년안에 Windows에서 현존하는 모든 소프트웨어의 인스턴스를 흡수할 것입니다. 이것은 대세이며 곧 적응될 것입니다. 앞에서 레거시 코드를 정의한 바와 같이, 코드의 수명에 관계없이 레거시 코드는 원본과 런타임 간의 정렬입니다.
.NET은 Windows 런타임을 변경합니다. COM 및 Windows SDK는 사장되지 않았지만 다른 모델을 기반으로 코드를 작성해야 합니다. 이 새로운 런타임 토대에 관계없이 처리할 수 있는 새 모델이 있습니다. 그리고 이 모델은 차후 Windows 모델이 될 것입니다.
Windows는 사장되지 않았지만 변경될 것입니다. COM도 사장되지 않았지만 .NET 클래스를 적용해야 하며, ADO도 아직 사용되고 있지만 ADO.NET의 .NET 기능이 ADO의 미래입니다.
.NET은 단순히 Windows 6.0이 아니며 ADO.NET은 ADO 3.0으로 명명할 수 있는 차원이 아닙니다. ADO.NET은 완전히 다른 새로운 플랫폼입니다. 그리고 나머지는 모두 다른 플랫폼 또는 통합된 경우 레거시 코드입니다.
레거시 코드는 제한된 수명이 없습니다. .NET이 실제로 출시되는 경우에도 사용자들은 이번 주 또는 6개월 후에 DNA 시스템을 작성하고 있을 것입니다. 하지만 이것이 확실히 잘못되었다고 또는 피해야 한다고 말할 수는 없습니다. 한마디로 시류에 역행한다고 볼 수 있습니다.
============================================
<마이크로소프트>사 자체의 보고서 내용, 땅야땅야님 블로그에서 퍼옴..
반응형