Walter,

1. .NET is not a data-centric language, but rather a general purpose development platform
9. .NET is not based on database technology. VFP is more geared towards that.

Very misleading. .NET provides data providers and the necessary integration with back-ends like SQL Server, to call stored procs where most of the data crunching should be done. I just spent a day designing some stored procs to process data, where a few years ago I would have brought back data and done the 'data munging' locally. Much of what is done locally can be done in the back-end.

2. You have very limited ways of working with a DML locally (with ADO.NET): You'll have to do most of your data stuff remotely.

Again, for the folks who build their stored procs, this generally isn't a big issue. See additional comments below.

3. Data binding is not as easy as in VFP.

Out of the box, I concede this point, but the shortcomings are not insurmountable. If one is interested, one can build a few generic classes and a binding interface to make future projects easier. If one uses the Mere Mortals Framework, one is further insulated from this issue. Yes, the next version of .NET is suppose to improve this.

However, prior posts have been misinformed on .NET's binding capabilities. Somewhere along the line, there was a belief that datagrids were slow when loaded with a table with thousands of rows. This just isn't true - a datagrid can be bound to a result set, so it generally loads in about the same amount of time if it's 5 rows or 5,000 rows. The fact that this was claimed without verification speaks to the issue I raised a few nights ago about accountability.

5. .NET generally is more low-level, meaning you generally need more .NET code to do the same as in VFP.

If one thinks along the lines of building a set of template classes to accomodate certain tasks, future project endeavors may find the actual ratio isn't as high as you'd think. This statement carries less and less weight as one becomes more experienced with the tool.

A .NET newbee tries to port his VFP application into .NET and does not realize that you should only download the data you need via a SQL command through ADO.NET in stead of USE Mytable and THISFORM.Grid.RecordSource = Mytable. This person might conclude that .NET cannot handle lots of data and present this as fact.

I've heard this before from you, and it's a highly specious argument. If this conclusion is indeed initially drawn, it's far more reflective of the person's lack of exposure/experience in remote/distributed architectures. But even for 'desktop/LAN' apps, a simple business object with a few table properties and a getdata() method takes care of this. Sadly, this isn't the only perceived shortcoming that has been presented as fact. Bottom line: this is as close to a non-issue as it gets.

A .NET developer might succeed convert his 'Tastrade' level application from VFP to .NET thereby concluding that it is easy to port YOUR application to .NET.

Please provide a specific instance where someone converted an app identified as 'Tastrade' level complexity, and then concluded that it was easy to port other apps.

Use sophisticated DML, (such as SQL, REPLACE ALL, SEEK, etc) on data that somehow got into the client. You'll have to program this functionality yourself.

ADO.NET has an equivalent of SEEK. It has the ability to filter result sets. You can code a generic REPLACE ALL function. One can accomplish many of these things in ADO.NET. They are just done 'differently'. In many instances, with more lines of code?...yes. Can you do 'everything' in ADO.NET that you can do with Fox cursors? No...but I've come to realize just how much should be done in the back-end to begin with. I don't believe that entirely validates the criticisms that have been leveled against ADO.NET.

Walter, I'm sorry, I'm really trying to avoid escalating this to a heated level, but these types of posts just don't offer a quality and substantive analysis of the tool. Yes, .NET has issues (just like Fox has issues) that will hopefully be resolved in the next issue, no question. Those who have used .NET can offer better arguments about the deficiencies of .NET than the ones presented here. Why? Because they dove into it, and built applications with it. But it is still a powerful development tool that can be used to provide business solutions.

I full acknowledge that it takes time to become proficient with .NET. As I said before, it's all about building a knowledge base, which is true for any development tool but doubly-so for .NET because of its sheer complexity. It also takes time to become knowledgeable enough about .NET to consistently make informed statements about it.


Kevin