>Please explain this argument. When I begin a new project, I'll at some point have to define application specific classes (as the same functionality/GUI occurs on multiple levels within that application). All this code is NOT part of a framework, but is gathered in a application specific classlib. Esspecially when talking data, I don't see any reason why I should force myself to use framework classes to do a simple SQL SELECT, LOCATE, SEEK, UPDATE, INSERT. I agree that in some cases design paterns like a bridge makes sense, but in the case of these functions which are so well defined and every self respected VFP developer knows what it does, using classlib functions for these functionality seems just counter productive and leading to less readability.

Very simple. When I start a new Fox app I copy in about 20 or so classes right off the top that contain business object framework, utility classes etc. This is reusable code I'll use for every app, so this is not application specific. On top of that comes application specific classes that are considered platform level - control extensions, application specific subclasses of framework classes mentioned above etc.

>So my experience says that for every application I'll have to define application specific classes, not beeing part of a framework. Within those classes, I'll use many complex functions out of the box without using a bridge to a framework class for many functions, just because they already well abstracted. This will mean that when going to do .NET development I'll try to implements VFPs DML functions into a classlib. When this is done, I totally agree, the amount of coding for every new system is not going to be much different from VFP. However, note that building such classlib with the same functionality of VFPs DML is a trivial and tremendous complex and difficult task.

If you ask to work that way. Most .NET developers wouldn't want to do things the FoxPro way.

If you do - then why would you even consider going to .NET (which you are not of course)? If you want to work 'like VFP', why not just work WITH VFP? <g>

As I said before, if you approach .NET from the Fox perspective and want to make things work just like Fox you will be immensely frustrated. While the Fox was works great, it's not the only way to do things in terms of data access or otherwise. And if doing thing the Fox way is so important - well VFP is your answer.

>Of course a much simpler path is to define a data handling strategy into a data layer which is much more simple and straightforward to implement, but then you're losing the granularity and flexibility of the VFP functions. And its funny that just the argument of granularity is used often in favour if .NET. When it comes to handling data, it seems a .NET implementation is either too granular (Do everything yourself again and again and again, like iterating and munging through ADO.NET collections)or not granular enough (Define the interface of a data layer and using business objects to handle the data related tasks). Well I'm sure it just a matter of time when granular functions that have an equivalent into the relational world of data (Like the SQL or XBase DML standard) becomes available, but until that day comes, it is clearly a disadvantage of the .NET framework.


The difference is an object based approach to data vs. a record base approach to data.

Using Collection is not only logical it's also easy. Whether you use SCAN or a FOREACH loop to iterate through data is that really so much of a difference?

You're stuck in the VFP mindset. This is neither wrong nor bad, but that's clearly what the issue is. Nothing is going to satisfy you unless it matches your VFP user experience... it'll be a long time if ever before alternatives
come about...