>>>>>Hi,
>>>>>
>>>>>I have rewritten my VFP 9 application completely using CursorAdapter approach and I like it a lot. (Create a BIZ object for each table of the database, drop it on a form, and then change or add records/rows via the BIZ object; works very well. The BIZ object is based on CursorAdapter).
>>>>>
>>>>>And I am wondering; if I wanted to use the same type of approach for an ASP.NET application, what would be the closest to VFP CursorAdapter in .NET world? TIA.
>>>>
>>>Still with a VFP back-end for data ?
>>>
>>>Update : just saw your similar post in ASP.NET so see that it will be SQL backend.
>>>
>>>I'll vote with Craig for EF on this one. If, as you say, your application is simple then the EF wizard should get you up and running quickly. You can either point it at existing DataTables or design the objects (model) and let it create the tables for you. And what you learn will give you a head-start if you need EF to handle more complex issues down the line......
>>>
>>>Not particulary recommending EF over nHibernate (which I've never used in anger) but certainly prefer it to working directly with DataTables and/or TableAdapers. I'll refrain from listing the reasons unless you are interested.....
>>
>>First, to your initial question, yes, still VFP back-end. It took me a long while to convert my VFP app to work with SQL Server (just installed first beta copy on a customer site). The ASP.NET has to work with whatever database is used by the Windows (VFP) application. Hence my ASP.NET uses VFP.
>
>That pretty much rules out EF then - although I see someone is working on a VFP Entity Provider (http://vfpefprovider.codeplex.com)
>
>>After this change, I will make the ASP.NET work with either VFP or SQL Server.
>
>So is there any relationship between this thread and the one in the ASP.NET section?
>e.g. are you talking about the same application but with differerent data back ends - or are the two completely unrelated?
>
>I don't know enough about your situation but, if the former is the case, my instinct would be to complete a SQL based version using EF and then work on a layer which would create identical POCO objects from VFP using OLEDB. At least that would allow a common code base for the rest of the app....
>
>>As far as EF, of course would like to know why "in anger"
>
>Just using 'in anger' in the colloquial sense - as in 'seriously", 'for production code" .
>
>> and would appreciate if you list the reasons.
>
>Always seemed daft to me that, in an object orientated world, we took nicely rationalized data from a well-built relational database and, using joins, immediately flattened it out to big and unwieldy DataTables etc. At least a good ORM model lets you view things in a intuitive way (e.g Customers have collections of Orders, Order have collections of OrderDetail etc. ) as well as being easier to pass around amongst layers (whether logical or physical)
>
>Just my 10c.......

1. The two threads are related (that is, dealing with the same application). Eventually VFP database will go away, so I am trying to learn what is the best way to deal with backend being SQL Server only. For now, I have a bunch of "IF" that will separate VFP-specific code and SQL-specific code.

2. As to your reasons, I will have to re-read your paragraph and learn some basic concepts, in order to understand what you mean. Not that you explain it badly; I just need to learn more.

Thank you for your help.