A ramble on Visual FoxPro (IV.)

Visual FoxPro is detached from Visual Studio

February 26, 2001, Microsoft announced the separation of visual FoxPro 7 from Visual Studio, is this good news or bad news? Let's analyze:

What have we lost?

Let's first observe that Visual FoxPro does not become a. NET language, and the technical loss is that you cannot develop a. NET based Web application.

The Visual Studio.NET is a tool that specializes in developing Web applications, which in the past and now Microsoft is hogging the "desktop apps" app market, now Microsoft is going to gobble up big web apps that are now controlled by other companies, so it's launched. NET architecture, Visual Studio.NET is the RAD (rapid development environment) for developing. NET based applications.

I think: at least in a year or two, we can not use Visual FoxPro to write the program will not be useful Visual FoxPro development of large-scale Web application requirements, the objective of most enterprises will not have to build an E-commerce site needs, we do not because of visual FoxPro is not a. NET language and loses our market-the application of a common enterprise (single user architecture, File server architecture, (two tier, three tier) client \ server architecture). And so on. NET really hot up, that will be a few years later things!

Of course as. NET language can also develop desktop applications, is it better for Visual FoxPro to become a. NET language? The author's view is: not necessarily. A netizen said: vb.net language like VC + + and like Java, has been completely unlike basic language, and so is to learn another set of language, there are many VB programmers this feeling, I heard that a lot of VB programmers abroad are also "worried". Even Microsoft admits: VB 6 and vb.net is a very different language.

Assuming that VB changes only grammatical features (which is already bad enough), then if Visual FoxPro is now a. NET language, the loss of its iconic function must be more than VB! We believe that the least tolerable of all this is that the Visual FoxPro data engine and processing tools will be lost, and, to be honest, most of us use Visual FoxPro as a fancy for its unmatched advantage in data processing. NET language using the Common runtime (Common Runtime Language), database functions are done through the components such as external ADO. In a technologically immature now, with Visual FoxPro running on the CLR, there is bound to be only three choices: Canceling the Visual FoxPro data processing component, allowing it to process data using the component, and adding Visual FoxPro to the public runtime; visual The FoxPro data engine is made into a component. It can be seen that none of the three options is reasonable, even if it becomes, then Visual FoxPro has become a sibuxiang thing.

Visual FoxPro and. Net

Visual FoxPro can support XML, Web Service, and COM very well. With them, Visual FoxPro can be integrated with. NET and can develop the most popular topic in. NET: Web Services.

Objectively, in favor of the development of visual FoxPro

Visual FoxPro as a member of Visual Studio is not a good development of "Fox's career", this view is the general consensus of National Fox friends. As a member of Visual Studio, Visual FoxPro more like other Visual Studio products, ignoring the development of its own characteristics, ignoring the needs of its users; product upgrades, service pack delivery cycles longer (to be completed by other products), if visual FoxPro 7 does not separate out, the release period will be at least six months late. By separating Visual FoxPro from Visual Studio.NET, at least two of the above issues can be improved, especially if the Visual FoxPro will focus more on the needs of users.

Face the challenge independently

The biggest disadvantage of Visual FoxPro from the Visual Studio.NET is that you have to face the market alone. The blunt is: can sell good? If the business of visual FoxPro 7.0 is good, then the visual FoxPro will develop very well--and that's a simple truth.

In all of Microsoft's development environment, Visual FoxPro is the only embedded data engine--VC, VB must plug data processing engine, such as: DAO, ADO, of course, VC can use the low-level API call to complete the task of database processing-this is visual FoxPro Features-for data processing, but if the blind to the Visual FoxPro merged into Visual Studio.NET, Visual FoxPro This feature must not be saved, which for Microsoft, the user is a loss. VB, VC does not have this problem--anyway they do not have built-in data engine, as long as. NET can call the data processing components on it!