weltzie, let me tell you my two cents on that: To use DataTable and DataSet, some use DataAdapter.
Command, Connection, DataReader are behind DataAdapter. I do prefer to avoid DataAdapter and even DataSet as long as I can, and go with a light solution using directly Command, Connection and DataReader to fill datatables in a Helper class to access data on Db. I used "Net" controls provided by visual studio only for demo purpouse and never had to use them (till now) in a real project. I also enjoy sometimes Linq, which provides another way to think at it (or apparently write less code to gain same purpouse. >that ADO.Net is the CORE part of .Net data access, however the reality is that >ADO.Net is the highest level of data access and is built upon the .Net Data >Providers that implement the interfaces in the System.Data. Exactly where did that page ( http://msdn.microsoft.com/en-us/library/system.data.aspx ) let you think Ado.Net is not "the highest level of data access" (to tell the truth, I always thought ,like Cerebrus, at Ado:net as the whole, not as a "top" or "bottom" or "underlying"), and furthermore I am not able to understand why "core" here could not mean "central as important" (what I understood is: ado.net is the technology that makes you intercat with db) instead of "central as buiding" (seems as if you understood "upon which everithing else -that I believe is in it - is build", but in the article MS said: "ADO.NET lets you build components " that is: on wihch you can build YOUR controls and classes and components to access data, and I understood: I can create a DBHelper which clould take care of connections and commands and Readres and give me out DataTable when I need them, or number of records affected by a method, or (but usually I use an intermediate layer for this) Employes as I require... But most important point in my opinion is : with .Net (not only with Ado.Net, but with the whole .Net) you can do same things in many ways. None of them will always be the correct way to do it; we all should use the way that best fit what the situation requires. And no, I do not believe a deliberate confusion has been introduced: I would have developed a more chaotic thing if it was my time do do it due to complexity of the whole. Or do you always write perfectly clear (but for who?) code? In any case, you should really see mine: *that* is true chaos, in comparison... ;-) 2010/8/7 Cerebrus <[email protected]>: > > On Aug 6, 7:58 pm, welzie <[email protected]> wrote: >> @Cerebus: That is EXACTLY why I posted it. However I have received >> zero response so far. I am left to assume my thought on data >> providers and ado.net are correct. > > Your blog post while opinionated at times does hit the mark mostly. It > is unconventional because I have rarely read such an interpretation of > ADO.NET. At the same time, it is not thought provoking enough or > detailed enough to merit a deluge of comments by readers. > >> Do most .netters only concern themselves with the classes that are >> called ado.net(DataTable, DataSet) and forget or ignore the data >> provider classes Command, Connection, DataReader? > > Firstly, it is my opinion that everything within the System.Data > namespace (and child namespaces) is part of ADO.NET. Not just two or > three classes. ADO.NET is much more than a set of classes, it's a way > of accessing data. So, I wouldn't say that. What makes you come to > such a conclusion? > > >
