Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
No simple way to do data in .NET!
Message
General information
Forum:
ASP.NET
Category:
ADO.NET
Environment versions
Environment:
C# 3.0
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01457894
Message ID:
01457946
Views:
94
>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....
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform