>ORM is the buzzword of the day. I know from talking to .Net developers, they just don't seem too upset when dealing with data. I have a friend who's evaluated several ORM tools available for .Net and is very happy with that approach.

Well, ORM is a buzzword alright and it works for many scenarios, but ORM along (for the purist) is a real bummer to work with and complicates application drastically. I thnk the real solution lies somewhere in the middle that provides object based access to field level data but still allows set level 'lists' that aren't bound to predefined strong types.

>With all the talk from Ken L. about the .Net programmers looking to VFP for ideas, what's an example or 2 of things you think would be benificial if they were added to .Net. And do you think they will actually make a difference to the .Net developer who is not coming from a VFP background?

I think #1 in my book would be a DataSet object or DataSet derivative that is bound to an underlying cursor. This would give better performance than what the DataSet provides today with larger data (although there are improvements in .NET 2.0) and would also need to provide the ability to further manipulate the data with requerying that is vastly improved over what DataViews can do. Requerying data once it's down on the client is awful in .NET and this is where most of the complaints and comparisons with VFP users come from. With .NET you are more or less forced into a more server centric approach.

I would also like to see improved databinding that is easier to use than what's there now or coming in ASP.NET 2.0. As i mentioned before I think that VFP's control source based model is easy to use, intuitive and handles a very large % of binding scenarios. While the .NET features are more flexible they are very wordy to set up and rely on Wizards in VS to make it accessible. It shouldn't be that way.


#1 is immediately useful to anybody who uses .NET and complaints in that department come from all corners not just the VFP community. # 2 is probably a much harder sell because VFP because Microsoft does provide alternatives. I bet though if DataBinding support was added to be similar to VFP it would be used far more than any of the other mechanisms simply because it is so much easier and logical to grasp.


>
>Thanks,
>
>PF
>
>
>>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...