Walter Meester
HoogkarspelNetherlands
General information
Category:
Visual FoxPro and .NET
>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.
The core of the .NET language is not based on database technology. If you take out ADO.NET you still can use other technologies to access data and still write applications that don't have need for hanlding data.
The trivial thing is that ADO.NET isself is not even a database engine. It is a piece of middleware that supports connection to a database and can store data in an object structure.
If you try to take the database engine out of VFP, VFP won't function anymore at all except maybe for some Fox2X style programming in Prgs. The OO model is tightly integrated into the local database engine and many resources are just tables. No, (visual) classes, forms, project manager, reports and labels.
>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.
It might or might not a big issue depending on the situation. Stored procs might ease the pain but are really no replacement to VFPs local database engine. There are a number of comments to make on writing stored procs for these kind of purposes. Stored procs do come with costs on a database server and might cause you problems in concurrency and resource consumption.
The fact is that with VFP you've got a choice where to process it, in .NET, not much of a choice.
>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.
You could use the same argument for building database applications in C++, but this really is a kludge in many ways. Sure you could build classes, but they don't reach further than your own applications and probably everyone is trying to reinvent the wheel to solve these issues, since there is no uniform solution to these kind of problems.
>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.
However this is not the whole story Kevin, Aside from a note I found that when binding to a datagrid the recordset is going to be validated in its entirety (which I really cannot check), there is definately an issue when wanting to presenting something else than the first record in the grid. A general accepted method with large recordsets is using paging, but that has a side effect that the record set is run through from the beginning for each page change. So with large sets it is going through the top to the point you want to display. There have been reports that beeing a performance problem. Whether that is significant in general I leave up to you, but this definately is a architectual difference from the way VFP handles grids.
>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.
Agian, you always can build classes as you do in VFP, but those classes have to be written in the language itself also. Those classes are not uniform and shared by every .NET user. IOW you can write a class that handles a REPLACE in a ADO recordset. You can use that as an argument, but that is not of much help to anyone who has not read your solution and has to deal with the same problem again. And again, to write a full equivalent to VFPs REPLACE statement is not an easy thing to do; not something you'd write in a few lines of .NET code.
> 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.
The argument was about how 'facts' are fabricated. This indeed is an example of drawing the wrong conclusion. But please note, again, that indeed you can open a multi million record table and bind it to a grid in just two simple commandlines with extremely good performance. Somthing that needs far more (and better thinking how to handle the objective) in .NET. as this is far more trivial.
>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.
Note that these were examples, though I've got the idea that from certain individuals they were drawing this conclusion. The point is that it might be easy to port a 'Tastrade level' application into .NET, but it is about impossible to create a data database driven ERP/ERM applications like BAAN, SAP, NAVISION into .NET. And there are a lot of gray shades between the two. Note that I'm implying that VFP is somewhere between the two.
> 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 use the PK as identifier to provide a simular function as SEEK(). But seek is more than that. Seeking records on other fields, maybe in conbination with descending indexes, filters and SET NEAR on is not provided.
And I know you can use rowfilters etc, but they are not an equivalent to SEEK(). Seek does a B-Tree search and set the record pointer to it (in ADO.NET I'd expect a reference to the actual row)
>You can code a generic REPLACE ALL function.
If you wan't to code a full equivalent of VFPs REPLACE command, please go ahead. This is not something you'd do easily as a FOR and or WHILE clause INDEX usage, multiple column replacements, error checking etc are not tasks I'd leave for joe average.
>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.
My intent is not make statements about the 'way to do things' in .NET. It is about its architectural missings. Of course there are ways to workaround issues (what you call differently), but often workarrounds are often kludges of missing functionality.
The missings in ADO.NET are often forcing you into a certain direction because you have no choice. Possibly bringing additional complexity. When it comes to handling data, in VFP, you've got far more options and you're able to choose what suits your bests. In .NET you have to take a step back because some things in regards to handling data are not possible/feasible/attractive in a certain way. You seem to dismiss the value of local data processing. Good for you, not for me. It is crucial to me. This is the reason why I regard switching to .NET would be a step back in this area. And why should I go with a product if I feel it is a step back ??
>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.
I fully agree that it takes time. Time and practise iself does not guarantee you can make informed statements. Knowledge about software development theory in general neither. In this thread I presented a number of facts, which you could not deny. We are not able to dive into the nitty gritty detail either as that becomes ridiculous also. You can blame me for not telling the whole story, but equally you did not provide the full difference in characteristic between a VFP grid and Datagrid either (And yes there are). You can make arguments about what you can do in ADO.NET but you do not draw a informed picture either. Implying that you can do a SEEK() in ADO.NET is misleading also, that beeing the thing you're accusing me of.
Look kevin, There are architectual difference between VFP and .NET, which makes one or the other more suitable on certain situations. I think there is no way you can convince anyone here otherwise. We can debate on whether these architectual differences are significant or not, but neither you nor me can look into eachothers situations, believes, frameworks, applications, etc. So forcing your view is as useless as forcing my view to anyone who already has made his stance. All we can do is use the facts as a solid base and discuss the relevance of it while having to accept that this might be futile discussion as there might be no wrong or right. The lurker has to make up his mind whether this is relevant to them or not.
Walter,
Walter,
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only
