시장에서 가장 유연하고 강력한 데이터베이스 관리 시스템인 Visual FoxPro는 길고 영광스러운 개발 역사를 가지고 있습니다. 창립 당시에는 Fox Software Company의 FoxBASE 제품이었습니다. "Fox"(국제 프로그래밍 커뮤니티에서 통칭)는 프로그래머를 위한 안정적이고 편리하며 효율적인 데이터베이스 제품으로 잘 알려져 있습니다. Visual FoxPro처럼 작동하는 제품은 세상에 없습니다. 독특합니다!
많은 사람들이 Visual FoxPro의 서비스를 즐겼지만 그것이 무엇인지 알지 못합니다. 이를 이해하기 위해 개발 궤적을 따라가 보겠습니다! 이것은 당신에게 그것에 대한 더 깊은 이해를 줄 것입니다.
FoxPro는 Xbase라는 DBMS 카테고리에 속합니다. Xbase라는 용어는 매우 일반적이며 FoxPro, dBASEIII PLUS, dBASEIV, FoxBASE 및 ARAGO와 같은 언어를 나타냅니다. Xbase는 원래 JPLDIS(Jet Propulsion Laboratory Database Management and Information Retrieval System)라는 메인프레임에서 사용되는 DBMS에서 유래되었습니다. 이 DBMS는 1972년 미국의 Jeb Long에 의해 개발에 성공했습니다. 지금까지 전 세계의 개발자와 프로그래머는 수천만 줄의 Xbase 코드를 작성했습니다.
1980년대 후반까지 FoxBASE는 dBase의 복제 시스템이었습니다. dBASEIII가 작업을 수행할 수 있는 한 FoxBASE는 더 빠르고 효율적으로 작업을 수행할 수 있습니다. FoxBASE에는 몇 가지 새로운 기능이 있지만 실제로는 큰 기술적 혁신이 없습니다. 단지 더 빠르고 더 잘 실행될 뿐이며 더 중요한 것은 dBASEIII와 호환된다는 것입니다.
FoxPro 1.0은 처음에는 호환성 원칙에서 벗어났습니다. 그래픽 사용자 인터페이스 디자인과 소프트웨어 개발 방법에 몇 가지 새로운 아이디어를 채택하기 시작하여 당시 이미 전망을 잃은 dBASEIV를 앞서게 되었습니다.
2.0부터 FoxPro는 진정으로 자신만의 특성을 발전시켰습니다. FoxPro 2.0이 출시되었을 때 몇 가지 핵심 기술이 포함되어 PC 데이터베이스 개발 시장에 혁신적인 변화를 가져왔습니다. 이러한 기술은 다음과 같습니다.
Rushmore 기술이 추가되면 상상할 수 없을 정도로 복잡한 여러 작업을 수행할 수 있습니다. 갑자기 수백만 개의 레코드가 포함된 테이블이 가능했을 뿐만 아니라 더 비싼 다른 기술로 전환하지 않고도 PC 데이터베이스 시스템에서 구현하기가 매우 쉬웠습니다. Rushmore의 가장 중요한 장점은 사용자 지출 없이 완전히 자동화되었다는 것입니다. 에너지와 시간. Rushmore 기술과 Fox 고유의 속도로 인해 Visual FoxPro는 오늘날에도 여전히 가장 빠른 데스크톱 데이터베이스 엔진입니다.
SQL 문은 FoxPro 2.0에서 도입된 또 다른 혁신적인 핵심 기술입니다. 처음으로 Fox 개발자는 전체 프로세스를 단일 명령문으로 대체했으며 이 지원은 Fox 데이터 엔진에 내장되어 있습니다. SQL 언어는 과거에도 그랬고 지금도 강력한 데이터 언어입니다.
FoxPro 2.0에는 보고서 및 화면 개발을 위한 WYSIWYG 도구도 도입되었습니다.
FoxPro 2.0에는 오늘날의 Visual FoxPro에 포함된 뛰어난 기능 중 일부가 포함되어 있습니다. GUI 디자인 서비스, SQL 및 매우 빠른 데이터 액세스는 확실한 특징입니다.
FoxPro 2.5는 DOS와 Windows에서 사용할 수 있지만 Windows 버전에는 "Windows"처럼 보이는 DOS 응용 프로그램의 모양만 있습니다.
특히 DOS 버전은 확실히 고전적입니다. 우리 주변에 그러한 시스템이 많이 실행되고 있습니까? 당시 누군가는 다음과 같이 말했습니다. 하드웨어가 업그레이드되지 않으면 이 소프트웨어는 더 이상 빨라질 수 없습니다...
1995년 봄 Visual FoxPro가 출시되고 나서야 또 다른 큰 개선이 이루어졌습니다. FoxPro(Microsoft는 이미 Fox Software Corporation을 인수했습니다). Visual FoxPro 3.0은 오랫동안 기다려온 몇 가지 기능을 추가하여 PC 데이터베이스 개발 커뮤니티에 충격을 주었습니다. 우리는 Visual FoxPro와 FoxPro가 매우 다르다는 것을 알 수 있습니다. Visual FoxPro FoxPro를 더 이상 호출하지 마십시오. 이러한 기능은 다음과 같습니다.
DBC라고도 알려진 데이터베이스 컨테이너는 저장 프로시저, 테이블과 관련된 데이터 규칙 및 개발자가 수년 동안 원했던 다양한 추가 데이터 기능에 대한 지원을 추가합니다.
원격 데이터의 원활한 연결. 원격 데이터 처리 연결에 관해서라면 누구나 RDO, ADO, BDE와 같은 데이터 처리 엔진을 떠올리곤 합니다. 그렇다면 Visual FoxPro는 원격 데이터의 원활한 연결을 위해 무엇을 사용할까요? Visual FoxPro만의 데이터 처리 엔진은 다른 개발 도구와 다릅니다! Visual FoxPro 데이터 처리 엔진은 ODBC 드라이버를 통해 원격 데이터베이스 서버와 "대화"합니다. 원격 데이터베이스 서버의 ODBC 드라이버는 Visual FoxPro 데이터를 반대로 해석할 수 있는 데이터로 변환할 수 있습니다. 또한 원격 데이터를 Visual FoxPro 데이터 엔진에서 처리할 수 있는 데이터로 변환합니다. 원격 데이터베이스에 ODBC 드라이버가 있으면 Visual FoxPro를 클라이언트 소프트웨어로 사용할 수 있음을 알 수 있습니다. SQL Server, Oracle 및 Access와 같은 일반 데이터베이스는 모두 ODBC 드라이버를 제공합니다.
Visual FoxPro에서 실제로 원격 데이터를 조작하는 방법에는 원격 뷰와 SPT 기술 두 가지가 있습니다. View는 데이터 처리, GUI 표시 및 보고서 생성을 위한 완전한 데이터 액세스 방법 세트를 추가하는 업데이트 가능한 SQL 커서입니다. 로컬 보기와 원격 보기의 두 가지 보기 유형을 지원합니다. 로컬 보기는 Visual FoxPro 테이블을 기반으로 하는 보기이고, 원격 보기는 ODBC 데이터 원본을 기반으로 하는 보기입니다. 또한, Visual FoxPro를 완전한 C/S 개발 환경으로 만들기 위해 뷰 외에도 데이터베이스 서버의 사용자 관리 등 뷰로 완료할 수 없는 작업을 완료할 수 있는 SPT(SQL Pass Through) 기술도 지원합니다. , 저장 프로시저 호출 등 View 및 SPT 기술이 등장한 후 Visual FoxPro는 원격 데이터에 액세스하는 주요 도구가 되었습니다. 전반적으로, 전사적 응용 프로그램을 만들고 원격 데이터 소스에 저장된 데이터를 사용하는 것은 Visual FoxPro 테이블 자체를 사용하는 것만큼 쉽습니다. 명령, 기능, 데이터 처리 및 데이터 액세스를 추가하면 아무런 차이가 없습니다. 다시 지적하십시오: Remote View 및 SPT 기술은 Visual FoxPro 데이터 처리 엔진에서 직접 지원됩니다. 이는 VB 및 VC의 외부 데이터 액세스 기술과 다릅니다(DAO, RDO, ADO...와 같은 구성 요소를 사용합니다). 따라서 Visual FoxPro를 사용하면 원격 데이터에 매우 효율적으로 액세스할 수 있으며 원격 데이터와 로컬 데이터를 완벽하게 통합하여 개발 효율성과 프로그램 실행 효율성을 극대화할 수 있습니다.
객체 지향 기술(OOP)을 완벽하게 지원합니다. 객체 지향 처리의 완전하고 강력한 구현은 소프트웨어 개발 조건을 크게 향상시킵니다.
강력한 개체 모델과 자신만의 클래스 및 하위 클래스를 생성하는 기능을 통해 소프트웨어 개발에 대한 새로운 접근 방식이 가능해졌습니다.
Visual FoxPro 5.0은 3.0의 업그레이드 버전입니다. 32비트 시스템입니다. COM 서버를 사용하고 생성하는 기능을 가지며, Visual FoxPro를 인터넷에 게시하는 기능을 지원하기 시작합니다. 이 버전부터 Visual FoxPro는 Visual Studio 제품군에 합류했으며 이 기간 동안 Visual FoxPro가 더 이상 업그레이드되지 않을 것이라는 소문도 나타났습니다.
Visual FoxPro 6.0이 등장하기 전, 마이크로소프트는 오늘날 .NET으로 진화한 DNA를 출시할 계획이었고, Visual FoxPro를 강력한 중간 계층 도구로 개발하겠다고 약속했기 때문에 앞으로 Visual FoxPro에서는 변화가 있을 것입니다. 주니어 사용자는 쉽게 접근할 수 없습니다.
Visual FoxPro 6.0에는 근본적인 변화가 없지만 몇 가지 변화는 매우 분명합니다. 액세스 및 할당은 개체에 입력된 데이터를 제어하는 데 있어 매우 창의적인 두 가지 방법입니다. 새로운 구성 요소 갤러리 및 기초 클래스를 사용하면 객체 지향 애플리케이션 생성으로 쉽게 전환할 수 있습니다. COM에 대한 지원이 더 좋아졌습니다. Server Pack 3 이후에는 Visual FoxPro를 사용하여 다중 스레드 COM 구성 요소를 만들 수 있습니다.
Visual FoxPro 7은 Fox의 첫 번째 시각적 버전으로, Visual FoxPro 3 이후 가장 혁신적인 제품 업그레이드입니다. 그 특성에 관해서는 나중에 이 글의 특별한 단락에서 설명하겠습니다.
Visual FoxPro의 언어는 Xbase, SQL, OOP로 구성됩니다. 이런 분해가 합리적인지는 잘 모르겠습니다. 저는 FoxPro의 개발 이력을 통해 위와 같은 결론을 도출했습니다. 실제로 위의 세 가지 항목은 Visual FoxPro에 완벽하게 통합되어 있으며 이미 Visual FoxPro와 긴밀하게 연결되어 있으며 분리할 수 없습니다. 많은 명령문과 함수로 인해 해당 항목이 속하는 범주를 구별하기가 어렵습니다. 게다가 Xbase라는 용어는 오해하기 쉽습니다. Visual FoxPro의 언어는 실제로는 10여년 전에 개발되지 않은 "죽은 언어"인 것 같습니다. , FoxPro의 모든 업그레이드(이제 Visual FoxPro 7이므로)에서 언어의 이 부분이 수정되고 추가됩니다. 나는 이것이 여전히 사실이라고 생각합니다: Visual FoxPro 언어는 "Visual FoxPro 언어"라고 불립니다. 이것은 이전의 Xbase와 다르며(기껏해야 역사적인 기원을 가지고 있습니다), 다른 프로그래밍 언어와도 다릅니다. 이는 이전의 VB가 VB가 아닌 Object Pascal 언어인 Delphi와 같습니다.
Fox가 시각화 시대에 진입한 이후 COM 기술에 대한 지원은 항상 Visual FoxPro가 과거, 현재, 미래에 걸쳐 지속적으로 개선해 나갈 영역이었습니다. 객체지향 프로그래밍(OOP)의 가장 큰 장점은 코드 재사용입니다. 그러나 OOP는 코드 재사용을 위한 탁월한 솔루션일 뿐입니다. 단순히 OOP 기술을 사용하려면 모든 개체를 하나의 언어로 완성해야 할 뿐만 아니라 응용 프로그램에 포함할 원본 프로그램 코드도 가져와야 합니다(Visual FoxPro 개발에서 클래스를 사용하는 것처럼).
이는 귀하나 귀하의 회사가 작성한 객체라면 문제가 되지 않을 수 있지만, 다른 사람이나 다른 회사가 작성한 객체라면 문제가 됩니다... 게다가 자원을 절약하기 위해 우리는 종종 원격 개체 컴퓨터에 많은 응용 프로그램이 있습니다. 이 작업을 어떻게 간단하고 안전하게 수행할 수 있습니까? OOP만으로는 부족한 것 같습니다! 그래서 Microsoft는 COM(Component Object Model) 기술을 제안했습니다. 이를 통해 우리는 다른 언어로 개발된 개체를 응용 프로그램에 내장할 필요가 없으며 개체를 분산 방식으로 사용할 수 있습니다.
COM 기술은 네 가지 기능을 제공하며 Visual FoxPro는 모든 COM 기능을 지원합니다.
ActiveX 문서를 사용하면 사용자는 한 응용 프로그램의 문서를 다른 응용 프로그램에서 편집할 수 있습니다. Word 문서를 Visual FoxPro에 포함하거나 연결하면 Visual FoxPro를 떠나지 않고도 Word 문서를 편집할 수 있습니다.
ActiveX 컨트롤은 개발자에게 시스템 기능을 향상시키는 방법을 제공합니다. 일반적인 응용 프로그램은 사용자 인터페이스를 향상시키기 위해 다양한 ActiveX 컨트롤을 사용하는 것입니다. 여기서 주목해야 할 점은 Visual FoxPro가 Cool bar 컨트롤과 같은 "컨테이너화된" ActiveX 컨트롤을 지원하지 않는다는 것입니다(7.0도 마찬가지입니다).
자동화를 사용하면 사용자가 하나의 응용 프로그램에서 다른 응용 프로그램이나 구성 요소를 조작할 수 있습니다. 일반적인 응용 프로그램은 Visual FoxPro 및 Office의 OLE 자동화 응용 프로그램입니다.
원격 자동화 또는 분산 COM(DCOM)은 구성 요소 배포를 지원한다는 점을 제외하면 자동화 기술과 유사합니다. 이는 Microsoft의 분산 애플리케이션 전략입니다.
Visual FoxPro는 Active Control(ActiveX) 개발을 지원하지 않지만, 서버 구성요소 개발은 지원합니다. 즉, 자동화 및 원격 자동화에 사용되는 구성요소를 Visual FoxPro로 개발할 수 있습니다. Visual FoxPro의 이 기능은 5.0부터 사용할 수 있습니다. SP 3의 6.0에서는 다중 스레드 구성 요소를 개발할 수 있습니다. Visual FoxPro의 향후 버전에서는 서버 구성 요소를 개발하든 Visual FoxPro를 클라이언트 프로그램으로 사용하든 자동화, 특히 원격 자동화에 대해 더 나은 지원을 제공하게 될 것입니다.
요약하자면 Visual FoxPro는 로컬에서 실행하거나 구성할 수 있는 미션 크리티컬, 전사적, 개체 지향 단일 수준, 이중 수준 및 다중 수준 응용 프로그램을 만드는 데 중요한 개발 도구입니다. 전 세계적으로.
Visual FoxPro는 더 이상 사용되지 않는 것인가요?
존경하는 바이지만, 이 질문을 듣는 것이 정말 지겹습니다. 나는 이 질문을 몇 년 동안 들어왔습니다. 소문이 나온 때부터 오늘까지 Visual FoxPro의 버전은 두 번 변경되었습니다. 즉, Visual FoxPro 6.0과 Visual FoxPro 7.0이 2001년 봄에 출시되었습니다. Microsoft의 공식 뉴스에 따르면 Visual FoxPro 8(아마도 이름일 수도 있음)이 이미 개발 중입니다. 저는 Visual FoxPro 9.0이 있을 것이라고 보장할 수 없습니다(마치 마이크로소프트가 그 당시에도 존재할 것이라고 보장할 수 없는 것처럼).
예상치 못한 사건(예: Microsoft의 붕괴, 업계의 큰 변화 등)이 없는 한 Fox는 순조롭게 발전할 것이라고 할 수 있습니다!
해외에서는 프로그래머나 회사가 사용하는 개발 도구를 투자로 간주합니다. Microsoft는 Visual FoxPro의 개발자로서 고객의 투자 권리를 보호해야 하는 것이 원칙입니다. , Microsoft는 500,000명의 사용자로부터 돈을 벌고 싶지 않는 한 500,000명의 사용자를 보유한 Fox를 감히 제거하지 않을 것입니다.
비주얼폭스프로가 탈락한다는 소문이 왜 나오는지 모르겠습니다. 그러나 지난 2년 동안 Visual FoxPro에 대한 Microsoft의 비공개 태도는 이러한 소문을 부채질했습니다. 게다가 비주얼폭스프로는 확실히 오해를 불러일으킬 수 있는 제품이기 때문에 후배들이 '그다지 좋지 않다'고 판단하기 쉽기 때문에 그런 소문을 더하면 '비주얼폭스프로는 정말 없어질 것 같다'는 착각이 들게 된다.
Visual FoxPro가 오해의 소지가 있는 제품인 이유는 무엇입니까? 그 이유를 다음과 같이 요약합니다.
객체지향과 프로세스지향의 논쟁
우리는 Visual FoxPro가 객체지향 언어라고 하는데, 거기에는 근거가 있습니다. 객체지향 언어에는 추상화, 캡슐화, 상속, 다형성이라는 네 가지 특성이 있어야 합니다. Visual FoxPro가 이 네 가지 기능을 지원하는지 확인해보세요!
물론 Visual FoxPro는 C, Object Pascal과 같이 오랜 역사를 지닌 언어이기 때문에 언어에는 프로세스 지향 형태소가 많이 포함되어 있습니다. 나는 많은 학교에서 학생들에게 Visual FoxPro의 프로세스 지향 언어 기능만 사용하도록 가르치고 객체 지향 교육을 무시한다는 것을 알고 있습니다. 대다수의 Visual FoxPro 프로그래머에게도 동일한 문제가 존재합니다. 우리는 이해해야 합니다: 우리는 Visual FoxPro의 강력한 객체지향 기능을 사용하지 않았기 때문에 Visual FoxPro가 객체지향 언어가 아니라고 말할 수 없습니다. 이는 비가 왔지만 비가 내리지 않았기 때문에 Tengu가 태양을 먹었다고 말하는 것과 같습니다. 일어나세요. 너무 유치하고 우스꽝스럽습니다!
우리는 Visual FoxPro가 수년간 데이터 작업에 있어 프로세스 중심 접근 방식을 따랐다는 것을 알고 있습니다. 이는 현재 널리 사용되는 개발 도구와는 매우 다릅니다. 저는 Microsoft가 이렇게 하는 데에는 이유가 있다고 생각합니다.
첫째, 프로세스 지향 데이터 처리는 XBase 언어 시스템의 유연성과 무작위성을 더 잘 활용할 수 있습니다. 다른 데이터베이스 개발 도구를 사용해 본 후 Visual FoxPro를 사용해 본다면 이 점을 이해할 것입니다.
둘째, 객체 지향 데이터 처리 구성 요소를 직접 제공하지 않는다고 해서 사용자가 자신의 데이터 처리 구성 요소를 캡슐화할 수 없다는 의미는 아닙니다. 많은 우수한 Fox 프로그래머들은 특수한 데이터 처리 구성 요소 자체를 캡슐화합니다. 이것은 Visual FoxPro 프로그래밍의 고귀한 영역입니다!
레코드 지향과 집합 지향 사이의 논쟁
저자의 피상적인 이해에 따르면 관계형 데이터베이스 처리는 레코드 지향 작업과 집합 지향 작업으로 나눌 수 있습니다.
다양한 개발 도구에서 지원하는 클라이언트 커서 시스템은 레코드 작업을 지향하며 레코드 간 절대 위치 지정을 지원하고 보다 명확하게는 SKIP, GO TOP 문과 같은 레코드 간 탐색을 지원합니다. Visual FoxPro는 의심할 여지없이 이 분야의 절대적인 대가입니다. 20년간의 언어 개발 끝에 수많은 레코드 지향 언어 요소를 수집했습니다.
이것이 우리가 반복적으로 강조하는 이유입니다: Visual FoxPro의 커서 시스템은 유연하고 강력합니다!
Oracle, SQL Server 등 다양한 대형 데이터베이스는 집합 중심 처리의 대표자입니다. 정통 SQL 언어를 보면 데이터 레코드가 동일하므로 모든 것을 논의해야 합니다. 관계와 조건!
기술이 발전하면서 사람들은 이 두 가지 데이터 운영 방식이 분리될 수 없다는 사실을 깨닫기 시작했습니다. 따라서 대규모 데이터베이스는 커서 픽셀을 지원하고 Fox도 표준 SQL 언어를 지원합니다.
제품 포지셔닝으로 인해 Visual FoxPro의 변화는 사람들이 느끼기 어렵습니다. Microsoft는 Visual FoxPro를 3계층 아키텍처(또는 다중 계층 아키텍처)용 중간 계층 개발 도구로 사용하기를 원합니다.
3계층 아키텍처란 무엇인가요? 첫 번째 계층은 사용자 인터페이스입니다. 여기에는 사용자가 입력, 출력, 쿼리 및 기타 작업을 수행할 수 있는 사용자 인터페이스가 포함되어 있습니다. 세 번째 계층은 데이터 계층입니다. 일반적으로 백엔드 데이터베이스를 참조하여 데이터가 배치되는 곳입니다. 주로 Oracle, SQL Server 등을 포함하며 정기적으로 데이터를 저장할 수 있는 큰 공간을 제공합니다. 두 번째 계층은 비즈니스 논리 계층(중간 계층)입니다. 일부 사람들은 다음과 같이 말했습니다. 데이터에 액세스하려면 1층 2층으로 갈 수 있나요? 물론, 누구도 지름길을 택할 수 없다고 규정하지 않으며 데이터베이스에서 직접 데이터를 가져오는 것이 빠르고 좋은데 두 번째 레이어를 만드는 이유는 무엇입니까?
비즈니스 규칙은 자주 변경됩니다. 예를 들어 근무일이 8시에서 10시로 변경되면 상사가 모든 사람에게 2시간만 일하라고 지시한 것을 컴퓨터가 어떻게 알 수 있습니까? 경기침체? 그걸 모르고 알려줘야 하는데, 컴퓨터가 많으면(예를 들어 100대) 프로그램을 하나씩 업데이트해야 하는 문제가 발생합니다. 이것이 인터넷에 떠있는 네트워크 프로그램이라면, 사용자들은 항상 새로운 프로그램을 다운로드 받을 수 있어야 하지 않을까?
더 중요한 것은 다수의 고객이 존재하는 환경에서 기존의 2계층 아키텍처는 엄청난 작업 압력을 견딜 수 없다는 점입니다. 일종의 중간 시스템을 통해 압력 균형을 달성해야 합니다. 중간 레이어의 또 다른 부분입니다.
중간 레이어는 그래픽 인터페이스 디자인 없이 코드를 작성하는 것으로, OOP 모드로 작성되므로 백엔드 데이터베이스의 특성을 숙지해야 할 뿐만 아니라, 데이터베이스의 특성도 고려해야 합니다. 프런트 엔드 인터페이스 도구 중 가장 중요한 것은 비즈니스 로직이지만 IIS, MTS(COM), NT 보안 설정과 같은 복잡하고 지루한 것에도 대한 이해가 필요합니다. 흥미롭게도 최근 몇 년간 Visual FoxPro의 다양한 개선 사항은 이러한 측면에 더 중점을 두었습니다. Visual FoxPro 7의 최신 버전에서는 중간 계층 개발에 대한 네 가지 질문을 통해 이에 대해 설명하겠습니다.
질문 1: Visual FoxPro는 안정적이고 효율적인 서버 프로그램을 개발할 수 있습니까? 예, 1999년에 출시된 Visual FoxPro SP 3에서 Microsoft는 Visual FoxPro에 다중 스레드 프로세스의 내부 구성 요소를 개발할 수 있는 기능을 제공하고 해당 작업을 지원하기 위해 새로운 런타임 라이브러리 VFPnT.DLL(n은 버전 번호를 나타냄)을 추가했습니다. 런타임에서는 구식 인터페이스 제어 요소가 많이 제거되어 크기가 작아졌습니다.
그러나 Visual FoxPro6 자체는 그다지 안정적이지 않기 때문에(SP4 또는 SP5를 추가한 후 개선됨) 이 훌륭한 기능은 Visual FoxPro 6에서 완전히 활용될 수 없습니다. Visual FoxPro 7이 등장하고 나서야 그 영웅적인 성격을 보여주었습니다!
질문 2: 분산 트랜잭션과 동적 로드 밸런싱을 어떻게 구현하나요? Visual FoxPro 7은 COM을 잘 지원하며 이 두 가지 문제는 COM을 통해 해결될 수 있습니다!
질문 3: 서버 프로그램으로서 클라이언트 프로그램은 어떻게 서버와 데이터 세트를 교환합니까? 이것이 Visual FoxPro 6이 개발한 Server 프로그램의 치명적인 약점입니다. Visual FoxPro는 데이터 처리에 사용되는 것으로 알고 있지만, 외부 세계와 데이터 세트를 자유롭게 교환할 수 없기 때문에 개발, 사용, 프로그램 운영의 효율성이 크게 떨어집니다. ! Visual FoxPro 7에서는 XML을 사용하여 대용량 데이터 세트를 빠르고 쉽게 전송할 수 있으므로 데이터 세트가 자유롭게 들어오고 나갈 수 있습니다. 이제 Visual FoxPro 6에서 사용한 "루프 속성" 접근 방식을 되돌아보면 정말 천국과 땅처럼 느껴집니다!
질문 4: Visual FoxPro에서 개발한 서버를 고객이 원하는 대로 수행하는 데 사용할 수 있습니까? 예, Visual FoxPro 7에는 ExecScript()라는 새로운 함수가 제공됩니다. 이를 사용하면 Visual FoxPro 사양을 준수하는 클라이언트가 보낸 여러 명령문을 한 번에 실행할 수 있습니다. 변수를 정의하고, 쿼리를 작성하고, 데이터를 업데이트하고, 테이블 구조를 수정할 수 있습니다...
Microsoft는 실제로 Visual FoxPro가 중간 계층에서 실행되도록 하는 연습을 하고 있습니다. 그러나 불행히도 국내 사용자 수준과 국내 소프트웨어 응용 분야로 인해 대부분의 Fox 팬은 Visual FoxPro의 급격한 변화를 느낄 수 없습니다. 그들에게 Visual FoxPro는 "변경되지 않습니다"!
Visual FoxPro는 데스크톱 응용 프로그램 개발에만 국한됩니까?
기술이 발전함에 따라 소프트웨어 기술의 적용이 계속 확장되고 있으며, 인터넷은 많은 개발 도구가 지원하기 위해 경쟁하는 응용 분야가 되었습니다. Visual FoxPro는 버전 5부터 인터넷에 대한 지원을 지속적으로 확장해 왔으며 최신 Visual FoxPro 7에는 웹 서비스에 대한 지원이 추가되었습니다. Visual FoxPro의 인터넷 지원은 세 부분으로 나눌 수 있습니다:
첫째, 간단한 HTML 변환. Visual FoxPro와 함께 제공되는 "웹 게시"는 이러한 유형의 도구입니다. 이는 HTML 및 DHTML 템플릿을 사용하여 Visual FoxPro 데이터의 웹화를 지원합니다.
둘째, Active Document 기술은 기업 내부에서 사용하기에 적합합니다. Visual FoxPro 응용 프로그램을 웹 응용 프로그램으로 빠르고 간단하게 변환하고 싶으십니까? 이 Active Document 기술이 최선의 선택입니다. IE에서 실행되는 앱 프로그램을 지원합니다. 단점은 클라이언트가 Visual FoxPro 런타임 라이브러리를 설치해야 한다는 것입니다. 이는 F/S 아키텍처에 속하며 인터페이스만 가능합니다. 실행하세요. IE에 있습니다. 빠른 개발과 여전히 전통적인 아키텍처를 기반으로 한다는 사실로 인해 이 기술은 기업 내에서만 실행될 수 있으며 일반적으로 광역 네트워크에서는 출시될 수 없습니다.
이 기술은 Visual FoxPro 6에서 제안된 기술입니다. 당시에는 도구 메뉴에 특별한 메뉴 항목이 있었습니다.
현재 Visual FoxPro 7에서는 이 메뉴 항목이 취소되었지만 Visual FoxPro 7이 Active Document를 지원하지 않는다는 의미는 아니며, 그다지 뛰어나지 않은 이 기술을 더 이상 눈에 띄는 위치에 배치할 필요가 없다는 의미입니다.
세 번째, COM 기반 웹 애플리케이션입니다.
Visual FoxPro는 COM을 통해 지원되기 때문에 실제로 웹 개발에 사용할 수 있습니다.
여기서 데이터베이스 개발 도구로서 Visual FoxPro는 FronPage와 같은 웹 인터페이스를 개발하기 위한 도구가 아니라는 점을 이해해야 합니다(아마도 Visual FoxPro는 미래에 웹 인터페이스 개발을 지원할 것입니다). Visual FoxPro는 웹사이트의 백그라운드에서 완전히 서버로 실행되어 다양한 응용 프로그램에 대한 서비스를 제공합니다. Visual FoxPro를 사용하여 작성된 COM 구성 요소는 IIS의 지원을 받고 백그라운드에서 다양한 작업을 수행할 수 있습니다. 이것은 Visual FoxPro의 실제 웹 응용 프로그램이자 일반적인 다중 계층 아키텍처의 중간 계층이기도 합니다!
이 단계에서 Visual FoxPro의 웹 지원은 세 가지 수준으로 나눌 수 있습니다:
FoxISAPI.
이것은 ASP 기술이 등장하지 않았을 때 IIS에서 ISAPI 기술을 통해 역동적인 웹 개발을 실현할 수 있었던 최초의 기술입니다.
웹 서버
ASP 기술이 등장했습니다. ASP 기술의 주요 특징은 서버 측 구성 요소의 응용 프로그램을 지원한다는 것입니다. Visual FoxPro로 작성된 COM 구성 요소는 IIS에서 실행될 수 있으며 ASP에서 호출될 수 있습니다.
웹 서비스
이것은 Visual FoxPro 7의 새로운 기능이며 현재 가장 널리 사용되는 기술입니다. 웹 서비스와 가장 큰 차이점은 웹 서버 구성 요소는 ASP 프로그램을 통해서만 호출할 수 있는 반면 웹 서비스는 SOAP 및 XML을 지원하는 한 클라이언트의 하드웨어 플랫폼이나 소프트웨어 플랫폼에 관계없이 모든 시스템에서 전역적으로 호출할 수 있다는 것입니다. .
좀 더 과장해서 말하면, 인터넷만 연결되어 있으면 웹서비스가 제공하는 서비스를 마음껏 누릴 수 있다는 것!
어떤 사람들은 다음과 같이 질문할 수 있습니다. VB 및 VC를 사용하여 개체 구성 요소를 만들 수 있는데 왜 Visual FoxPro를 사용하여 동일한 구성 요소를 만들어야 합니까? Microsoft는 이 문제에 대해 다음과 같은 특별한 의견을 제시합니다. 빠르고 재사용성, 언어 간 재사용성. "빠르다"는 것은 Visual FoxPro로 개발된 구성 요소가 매우 빠르게 데이터를 검색하고 처리할 수 있으며 Visual FoxPro가 문자열을 매우 빠르게 생성할 수 있다는 것을 의미합니다. 얼마나 빠른지 다들 경험해 보셨을 텐데요, 문자열 생성 속도에 대한 데이터도 있으니 한번 살펴보시면 좋을 것 같습니다. - 1M data 언제. 텍스트를 작성하는 데 VC 6.0 프로그램은 3.5초, VB 6.0 프로그램은 11초, Java 1.1.5는 24초, Visual FoxPro 6.0은 7초가 걸렸습니다. "재사용성"은 Visual FoxPro에 "교차 기능"이 있음을 의미합니다. 언어 재사용성"은 Visual FoxPro로 작성된 개체가 컴파일 후에 COM 및 COM 개체 구성 요소가 되어 다른 언어에서 사용할 수 있음을 의미합니다.
Visual FoxPro를 "저급 제품"이라고 생각하지 마세요. Visual FoxPro를 데이터베이스(DBF Base) 품질 측면에서 평가하든, 개발 환경 측면에서 평가하든 "고급 도구"입니다. .
많은 사람들은 Visual FoxPro가 파일 서버 아키텍처를 갖춘 단일 사용자 시스템이나 소규모 네트워크 시스템을 개발하는 데에만 사용될 수 있다고 생각합니다. 이것은 오류입니다. C/에 대해 이야기하는 많은 사람들이 이 무식한 진술을 사용합니다. S, 3티어 아키텍처에 관한 책이 있습니다(특히 VB, PB 및 Delphi에 관한 일부 데이터베이스 프로그래밍 책). Visual FoxPro를 사용하여 C/S 구조의 시스템을 개발할 수 있다는 점을 책임감 있게 말씀드릴 수 있습니다. 여기에 언급된 C/S 아키텍처는 절대적으로 정통하며 일부 F/S 아키텍처로 모든 사람을 속이는 것은 아닙니다. C/S 아키텍처에서는 클라이언트 개발 도구로 Visual FoxPro를 선택하고 백그라운드에서 Oracle 및 SQL Server와 같은 네트워크 데이터베이스를 사용하며 Visual FoxPro에 내장된 원격 보기 및 SPT 기술을 사용하는 경우가 많습니다. 완벽하게 해결되었습니다. 여기서는 자세히 설명할 수 없지만 개발 시 Visual FoxPro 로컬 엔진의 역할만 소개하겠습니다. Visual FoxPro의 로컬 엔진은 특히 강력합니다(위에서 수백만 개의 레코드를 쉽게 처리할 수 있다고 말했습니다). 시스템을 설계할 때 원격 데이터를 로컬 데이터와 쉽게 결합하고 네트워크 데이터 트래픽을 매우 간단하고 효과적으로 제어할 수 있습니다. 시스템 작업 효율성(VB, Delphi, PB 책을 많이 읽었지만 네트워크 데이터 흐름을 제어하고 시스템 작업 효율성을 향상시키는 방법에 대해서는 거의 논의하지 않습니다. 무시하기 때문인지 다른 이유 때문인지는 모르겠습니다).
내 생각에는 Visual FoxPro의 로컬 엔진이 C/S 아키텍처에서 적어도 세 가지 훌륭한 용도를 가지고 있다고 생각합니다. 하나: 자주 변경되지 않는 데이터를 로컬에 저장하는 것입니다. 우리나라의 우편번호와 지역 간의 관계는 상대적으로 안정적인 데이터이고, 데이터의 양은 항상 수천 건에 달하는 것으로 생각됩니다(구체적인 상황을 자세히 조사하지는 않았습니다). 클라이언트 컴퓨터에서는 우편번호 및 관련 정보를 이용하여 로컬에서 데이터를 얻을 수 있어 네트워크 자원을 절약하면서 높은 시스템 효율성을 얻을 수 있으며(C/S 개발의 중요한 원칙) 이를 서버에서만 통합할 수 있습니다. 우편번호가 변경되면 클라이언트 컴퓨터의 데이터를 업데이트, 다운로드 및 업데이트합니다. 동일한 기능을 얻기 위해 다른 소프트웨어를 사용하는 경우 Visual FoxPro보다 확실히 더 번거롭고 효과도 Visual FoxPro만큼 좋지 않습니다. 이는 Visual FoxPro의 데이터 엔진이 원격 데이터 읽기를 직접 지원하고 로컬을 잘 통합할 수 있기 때문입니다. 데이터 및 원격 데이터; 두 번째: 오프라인 데이터 패키지. 회사에는 출장 중인 사람들이 항상 있습니다. 마치 자신의 사무실에 있는 것처럼 노트북을 사용하여 수천 마일 떨어진 곳에 있는 고객과 주문을 하고 계약을 체결할 수 있습니까? 직장에 복귀하면 노트북을 서버에 연결하고 업데이트를 보내기만 하면 됩니다. Visual FoxPro의 오프라인 보기는 경제적이고 효율적이며 안전한 솔루션입니다(물론 원격 전화 접속을 사용하거나 Visual FoxPro가 할 수 있는 웹 사이트를 구축할 수 있습니다). 실제로 오프라인 데이터 패키지에는 중요한 기능도 있습니다. 다운로드한 데이터가 큰 경우(꼭 필요한 경우가 아니면 시스템을 이와 같이 설계하지 마십시오), 이 경우 오프라인 보기를 사용하면 데이터 세트를 자동으로 다음으로 변환할 수 있습니다. Visual FoxPro의 빠른 속도를 최대한 활용하는 물리적 테이블. 작업이 완료되면 유연성을 통해 백엔드 데이터 소스를 온라인으로 업데이트할 수 있습니다. 모든 것이 간단합니다. 내 생각에는 오프라인 보기가 C/S 시스템에서 Visual FoxPro의 판매 포인트임이 분명합니다. ADO도 비슷한 기능을 지원하지만 확실히 Visual FoxPro만큼 효율적이지는 않습니다. Visual FoxPro에 있는 대부분의 파일 형식은 실제로 DBC, SCX, FRX 등과 같은 DBF 파일이라는 것을 알고 계셨습니까? 이러한 파일 형식은 모두 Visual FoxPro의 로컬 엔진에 의해 구동되어 복잡한 작업을 완료할 수 있습니다. C/S 구조를 설계할 때 사용자 설정과 사용자 정의된 파일 형식을 저장하려면 다른 소프트웨어보다 Visual FoxPro의 로컬 엔진을 사용하는 것이 확실히 더 쉽습니다. 왜냐하면 변경하지 않고 수프를 변경하는 방법을 사용하기 때문입니다. 약이지만 간단하고 효율적입니다.
Visual FoxPro가 C/S 시스템을 개발할 때 가장 특징적인 점은 원격 데이터에 대한 제어가 로컬 데이터베이스를 통해 구현된다는 점입니다. Remote View와 Connection은 로컬 데이터베이스의 개체로 완벽하게 연결됩니다. 로컬 데이터와 원격 데이터. 클라이언트 측에서 원격 데이터 논리를 설정하는 이러한 접근 방식은 최신 ADO.NET과 유사합니다!
3계층 아키텍처에서 Visual FoxPro는 어떤 수준에서든 작업 역할을 할 수 있지만, 중대형 시스템의 데이터베이스 부분은 네트워크 데이터베이스를 기반으로 해야 한다고 생각합니다. 클라이언트 인터페이스로 Visual FoxPro를 사용하는 것도 가능하지만 일반적으로 기업 내에서만 사용이 제한됩니다. 인터넷에서는 일반적으로 IE를 클라이언트 인터페이스로 사용합니다. 3계층 아키텍처에서 Visual FoxPro는 중간 계층 개발에 가장 적합합니다. 간단하고(개발 난이도는 일반 Visual FoxPro 프로젝트와 크게 다르지 않습니다.) 빠른 문자열 생성, COM 기술 지원, MTS) COM 기술로 XML을 지원하고(Visual FoxPro 7.0은 XML 관련 3가지 기능 제공) 강력한 로컬 데이터 엔진과 유연한 데이터 처리 방식을 갖추고 있으며 멀티 스레드 서비스 구성 요소 개발을 지원합니다.
어떤 사람들은 다음과 같이 질문할 수 있습니다. ASP 스크립트 언어를 사용하여 웹 시스템을 개발할 수 있는데 중간 계층을 추가하는 이유는 무엇입니까? 실제로 현재 시중에 나와 있는 웹에 관한 대부분의 책들은 전체 시스템을 개발하기 위해 스크립팅 언어를 직접 사용하고 있는데, 심지어 일부는 하드웨어가 점점 빨라지고 있기 때문에 스크립팅 언어를 사용한다는 책을 쓰기도 합니다. 전체 시스템을 개발하는 데 사용됩니다. 이렇게 말하는 작성자는 대개 웹 애플리케이션 개발에 대한 실제 경험이 없는 사람들입니다. VBScript와 같은 스크립팅 언어는 해석 언어이며 운영 효율성이 매우 낮습니다. 웹 시스템 개발에 대한 전통적인 접근 방식은 응용 프로그램 논리를 COM 및 DCOM 개체에 작성한 다음 소량의 스크립팅 언어를 사용하여 이러한 개체를 구동/사용하는 것입니다. 이렇게 하면 시스템 개발 중에 작업 부하가 커지지만 모든 데이터 개발에 적합합니다