Yeah I agree with most of what you say.

I guess I don't view VFP as a data platform any more than more than I consider ADO.NET a data platform. In those terms those two are conceptually similar - they provide the core data access system layer to provide the raw data access and manipulation. If you want to build something sophisticated you likely will need to build on top of it. VFP makes raw data access somewhat easier with cursors vs. .NET's data sets, but again conceptually these are on similar levels.

Back in .NET 1.x I built an ADO.NET based data access layer that was based on datasets and modeled very closely to the wwBusiness classes I introduced with Web Connection. This layer is pretty simple in its implementation and functionality, very light weight and it worked very well for many applications. It's functional and provides most of the functionality that I was to from VFP based applications. In fact if you compared code between VFP and .NET side by side (like the original Web Store implementation) there were more similarities than differences. I guess that's what I'm getting at - these abstractions were no harder to build in .NET than in VFP and provide pretty close functionality parity between what I see in .NET and VFP.

It worked but it too was an abstraction that had its abstraction failures and that's were OR/M tool provide much richer functionality in many cases. At the same time you have to remember though that OR/M tools provide functionality that goes way beyond what VFP has ever provided out of the box or even with add on tools so comparing this to stock VFP is like comparing apples to oranges in the worst way :-}.

My point here is that .NET may not offer the best solutions out of the box, but with a reasonable amount of effort on your own (or a third party tool) you can get data access to work the way you want to OR/M or otherwise.

Understand I'm not disagreeing with you though - I know the travails - I've looked into a ton of OR/M solutions and none of them can serve ALL of my data access needs which IS a definite bummer. That's why a layer of abstraction ontop at the application layer can often provide that 'security' that comes with knowing I can swap in a different data layer at a future date.

+++ Rick ---


>I guess it depends on what you call prefabricated. When I purchased Web Connection, I expected it to "just work" and it did. I still had to understand some stuff, but a lot less than it would take to build it. And best of all it was easily comprehensible, at least the parts in VFP that I could (and would want to) examine. Similarly with something like Visual WebGui: pretty much, I expect it just to work.
>
>Yes, you can still use ADO.Net and DataSets in .Net, which proves to be a good thing. Rudy Lacavora, who seems to know his data frameworks, has created an Agile ADO.Net Persistance framework, http://rlacovara.blogspot.com/2010/01/agile-adonet-persistence-layer-part-1.html , that looks to be highly modifiable, light, and fast. And simple. If I have to do straight .Net, that looks to be the best chance to leverage the metadata we have (in xCase, with high extended attributes), by modifying what he's done to fit our circumstance (so much for prefabrication, eh?).
>
>VFP did have a data strategy as I see it: local cursor on top, any backend dynamically available underneath, metadata natively available. It could be implemented through a remote dbc, with the connection string being used in the USE command to switch backends; or through cusoradapters. It's not that it can't be done in .Net: but boy, it sure takes a lot of code to make it happen, and the sheer number of alternative ORM frameworks suggests to me that no one is too happy with any particular one of them. Which in turn suggests to me that there is a problem at the ORM conceptual level, not in the implementation (the folks building these ORMs are smart people, every one of them from what I can tell).
>
>VFP, of course, does not need an ORM, because the static type of the fields does not need to be known. And if they had to be known, the information would be available in the free table itself, or from the dbc. And that's the nub of the issue for me: that folks have to struggle with ORM's (and I don't think struggle is too harsh a term, based on the conundrums folks find themselves in -- e.g. http://www.mikesdotnetting.com/Article/109/ASP.NET-MVC-Entity-Framework-One-to-Many-and-Many-to-Many-INSERTS, although I could have referenced your articles where you relate the gotchas you've encountered <s> ) because of the nature of data access in .Net. Or they have to struggle with L2S. Or they have to lobby to not have L2S deprecated. From the outside, it looks like a nightmare.
>
>I'm not anti-.Net by any means, fwiw: there are some great assets in the .Net ecology. Gibralter combined with PostSharp look to be incredibly powerful, in a prefabricated <s> way. VisualWebGui (which I got onto because of a mention in one of your blogs, I believe, or perhaps it was a white paper) is incredibly powerful. WCF (after a few tries under other names) seems to be really useful. We're all better off having these and other assets available. But if we can do that without wasting our time with (what I see as) an ill-considered data access methodology, we'll also be better off. At the least, that's what VFP.Net will have to offer, i.e., the ability to build .Net datasources in a sane manner, while opening up the use of .Net resources generally.
>
>And thank you, once again, for the pathfinder role you have played (well, it looks like work, a lot of work, to me) in the real-world use of .Net technologies, and for sharing your experiences. Your blog is a refreshing change from the regurgitation of MS release notes so prevalent on .Net blogs.
>
>>>And in small but important ways, it happens within the .Net ecology. Think "stored procedures are good" in .Net 1.1 to "stored procedures limit scalability" now (the latter being what SQL Gurus have been saying for 10 years at least). Think of ado.net to Entity Framework, Linq2SQL to , well, maybe Linq2SQL, etc. .Net developers have got to like roller coasters, because they've been on a continuous rollercoaster ride for 8 years regarding data access. Well, I guess riding a surfboard on those big waves is pretty much the same, which might explain why I see you diving into each new technology as it comes around. As they say here in Kentucky, Bless Your Heart. <s>
>>
>>Uhm how is that different from VFP for example? In VFP there was never a real 'data access strategy' just a core DDL engine and a SQL (Rushmore) engine. To build sophisticated business apps you typically still had to use something on top of it like a framework that provided the same sort of abstraction that we have in .NET today. This means you can still today use raw ADO.NET and DataSets just as you could when .NET 1.1 was current.
>>
>>The point is as developers we are supposed to make intelligent decisions about technologies we utilize. Yet fewer and fewer people are willing to make the commitment to actually examine technology - they expect some pre-fabrictated that just works which IMHO is just NEVER going to happen.
>>
>>+++ Rick ---
>>
>>
>>>
>>>Hank
>>>
>>>>Uh, of course <s>...
>>>>
>>>>I suppose this should be pretty obvious to anyone: It doesn't matter which plaform you choose ultimately you as a developer you are dependent on the 'producers' of that platform and their vision whether it's Microsoft or some soft pedaling Open Source consortium. Regardless of choice you can get 'stranded' with old tech or abandoned when the folks in charge lose interest or go off to greener pastures.
>>>>
>>>>I think a lot of folks on this forum feel personally spited by Microsoft for discontinuing FoxPro even as its popularity nose dived years before the plug was actually pulled. I think you can hardly blame Microsoft for no longer wanting to support this product when even the lead loyal and dedicated lead developers were starting to lose faith and were rapidly redeploying inside of Microsoft.
>>>>
>>>>I understand that feeling of sitting on a sinking ship. I've been through it a few times in my career and it sucks royally, but I would argue that by the time it gets to that point it's actually a good thing to get tossed off the boat and into the cold reality beyond...
>>>>
>>>>+++ Rick ---
>>>>
>>>>>Hi Jess,
>>>>>
>>>>>re: dependency on MS, and MS controlling your future.
>>>>>
>>>>>That is so obviously true that I can't imagine how you would support the opposite side of the question. Ask not just the VFP developers of 2004, but the VB developers of 2004.
>>>>>
>>>>>Now, whether that is a bad thing is another matter entirely. Python is a great language; an argument can be made that of the non-Functional languages, it is the best conceived language (it should be: this was the initial consideration in creating it, if you've read Guido's writings on it) and is at least as well implemented as any of the others. Their PEP process, through which changes enter the language, is a model for all other languages to follow (but you will be a long time waiting to breathe if you hold your breath waiting for MS to adopt a similar process).
>>>>>
>>>>>And no matter how great Python is (it is one of the few official languages at Google, Yahoo, etc.), ISV's who sell to a range of customers from mom-and-pop's to mid-level corporations are more competitive when using MS products. It's all about perceived safety, from the customer's perspective. The customers at that level (and above, actually, in my limited experience there) don't care whether you are using an old-fashioned file drop or MSMQ or WCF or Biztalk (well, they might care if you use BizTalk because of the exorbitant licensing fee and the need to allocate another server). They are concerned about sleeping at night, thinking (wrongly -- the number of bugs in MS Products and OpenSource products is roughly the same; and OpenSource bugs average pretty much just as long as MS bugs in terms of time to being fixed.) that using a product built on the Microsoft technology stack is the safest way to go.
>>>>>
>>>>>So, you can make the case that Microsoft offers the most efficient development experience (thanks as much to 3rd-party vendors as to MS -- think ReSharper, think Intragistics and Telerik, think nHibernate or Habanero, etc.), and you can make the case that Microsoft keeps trying to get it right (I was told 4 years ago that it would be the 5th or 6th version of Visual Studio -- VS2010 is the 5th -- before VS had incorporated most of the features of VFP). If they make that goal for VS2012 or whatever it will be, I will be surprised and happy. Anyway, you can make all these claims, and support them in a reasonable fashion. But you can't claim that your future isn't controlled by MS. That's a bet, a wager, that you (and I) are making, that our basis for making a living, and in my case at least the competitive edge I've had in customized development tools, won't be flushed down the drain the same way that VFP and VB were. I think it's a good bet for a variety of reasons (the .Net infrastructure is so large that abandoning it would be extremely difficult), but it's something over which you and I and all the other developers have no control.
>>>>>
>>>>>Hank
>>>>>
>>>>>>>>Now that you're no longer dependent on MS, do you think you're totally free. No. You're becoming dependent into something which happens to be not an MS thing. And if someone decides to make use of MS product, it doesn't mean MS holds control of his/her future.
>>>>>>>>
>>>>>>>>I also have a good grasp on PHP, but .NET is what makes us rich.
>>>>>>>
>>>>>>>Jesse,
>>>>>>>
>>>>>>>I do not want to be rude as well. But these comments show you have not paid python the kind of attention it deserves. Even if you prefer to stick to an MS-only environment. Which of course may make a lot of sense. Python belongs to a completely different league. On a lot of grounds. Including non technical ones. The way the software architecture is evolved is both effective and, I am looking for an adequate wording, both convivial and vivacious:)
>>>>>>>
>>>>>>>Regards
>>>>>>
>>>>>>Francois,
>>>>>>
>>>>>>My statement is not about Phython which I have nothing against. I just stated my view against his view of dependency on MS products and MS taking hold of his future just because he's using them which to me is not correct. Well, it's his feelings against mine which is not a big deal I think. It's just a 2 cents opinion.