Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
No simple way to do data in .NET!
Message
From
30/03/2010 04:28:48
 
General information
Forum:
ASP.NET
Category:
ADO.NET
Environment versions
Environment:
C# 3.0
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01457894
Message ID:
01458026
Views:
92
>>>You know, I guess I was spoiled with Visual FoxPro; it seems that Microsoft (and earlier with Fox Software) took such a simple approach to handling data that I cannot now understand how it is that this can be made so complex in .NET.
>>>
>>>Yes, I am complaining.
>>>
>>>I am pouring through C# books, and all kinds of other books, and I am telling you, there is no simple way to do data in .NET. Of course, admittedly, I am speaking from inexperience with .NET. I am still trying to learn C#, much less how to handle data. Still, data handling, in my opinion, is a much more complex matter in .NET. Why does it have to be this way? It seems that there is a multitude of ways to handle data, using LINQ, ADO.NET, and so on. I just don't know where to begin. I just ordered Murach's ADO.NET 3.5 with C# book to see if this might help me a bit.
>>>
>>>Also, a few years ago when I got into C# in some local colleges, C# also seemed cryptic to me, but it now seems much easier. I guess it is a matter of time and experience. I don't think it is this way entirely with .NET data handling. There seem to be many more steps to handling data, unlike VFP and other xBased languages.
>>>
>>>Okay, I am finished with my complaining for now. :)
>>>
>>>Does anyone want to help me complain, or perhaps direct me to a simple tutorial on .NET data-handling?
>>>
>>>Has anyone else on UT here felt just as frustrated as I am feeling, or did y'all get over it 3 or 4 years ago while I was still making money with VFP?
>>
>>Chipping in on this thread a bit late but:
>>
>>Firstly - no one has really pointed out that just about all data-access tecnologies in the .NET world (LinqToSql, EF, nHibernate etc,etc) sit on top of the ADO.NET components. Understanding ADO.NET is not time wasted regardless of the path you choose...
>>
>>Secondly - putting a lot of code in T-SQL is fine if you know you can stick with MS SQL. But if you may want to move to a different back-end then you will have a lot of re-writing ahead of you. Also, at least at present, the current ORM options don't work very well with SPs on the backend ( although I can't speak out of experience for nHibernate - if someone knows differently?.....)
>>
>>Thirdly (and I don't think anyone has suggested otherwise) - don't bother with LinqToSql. If you're sticking to the MS camp then use Entity Framework....
>
>You're probably right about that. Regardless of which data direction one chooses to go in .NET, once you understand ADO.NET the fear and loathing go away. I can't recommend the Murach book highly enough. It comes in both C# and VB flavors.
>
>http://www.amazon.com/Murachs-ADO-NET-Entity-Framework-Murach/dp/1890774537/ref=sr_1_2?ie=UTF8&s=books&qid=1269925352&sr=8-2
>
>http://www.amazon.com/Murachs-ADO-NET-LINQ-Entity-Framework/dp/1890774529/ref=sr_1_1?ie=UTF8&s=books&qid=1269925352&sr=8-1

I don't think I have a single title from murach on the shelf. No particular reason why not - I guess, like a lot of people, I tend to stick with formats (and thus publishers) that I'm used to. For a long time that was Wrox; now it tends to be Apress. If I had the opportunity to browse a bigger range in a bookstore then I might be making different choices :-{

FWIW my current read is a Charles Petzold : 3D programming in WPF. Algorithmic mesh geometry, matrix transformations, quaternions, - but I've only got as far as 'how to build a chair' :-{
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform