EDN Admin
Well-known member
I am undergoing a course in .NET development, but things were not made clear at all when entering the ADO.NET subject.
I will outline what my understanding of everything I have read about ADO.NET till this point allows me so, I would very much appreciate corrections and insights into anything that sounds incorrect, redudant or should be enfasized. I am explicitly leaving
some points in bold when I would like some better foundation. So here I go:
ADO.NET is nothing more than a collection of objects/components - a database access API - to provide us the most used mechanisms (perhaps there are no other options?) of accessing data stored in databases.
Depending on what you want to do - as always - you make use of the appropriate components of the API.
a) If you want to build commands fully and independently in the client side ( perhaps a reason to choose this one is Batch/offline processing? ),
a connection and a command object are everything you need - as far as I understand. (Here I would like someone to clarify, besides whether what I have just stated is correct - if there is any reason to use a SqlDataAdapter in such cases. I
have been making DML (inserts, specifically) simply building the command object appropriately and having it executed.
My understanding says SqlDataAdatper is useful when working with DataSets, and does not offer any exclusive feat that I may lack in a command object - if I am not working with DataSets ).
b) If what you want is to manipulate the data in-memory - instead of these manipulations being made in the database server (say... any sort of (business) logic that you do not want it made in the server side), then you are better in picking a DataSet
object and a SqlDataAdapter to work with. (although not much clear as to why...
does it build DML commands automatically, based on some definitions you provide when creating the DataSet, and - since the dataset has as one of its features knowing how to keep track of any changes made to the source data from the time it was loaded into memory
- you are free of having to write the corresponding DML statements to update the database and all you have to do is call Update from the SqlDataAdapter object? )
c) If yet you have a different need - you wish to work/think on a different model/representation of your data, other than the one existent/present in the database - you can that resort to the Entity Framework. There, you can create a new model of representing
the data of your business, on the top of the one in the database - that will reside/exist only at the .NET side - and working with the proper Entity Framework objects (object context or the entity container, to mention a few (again from what I understand!))
you have the benefit of all the coding required for connecting and communicating between this new model and the "real" one, that exists in the database - being done automatically by the EF API. If I am correct, then I owe this understanding solely to Google/MSDN,
because the course gave the impression that we would always/only use the Entity Data Model to create a visual representation within .NET of our database model. This, ultimately, does not justify at all developing a new component for ADO.NET and all the
fuss around it. I am assuming that this impression passed in this course definitely does not touch the reasons why the Entity Framework was developed in the first place (and which hopefully I figured out...)
So, if you reached this part of the "question", thank you for your willingness to help (and perhaps even to sharpen your understanding, which is what happens when we have to teach others and face their questions, which may not always be ours) - and please
share whatever insights you may have about anything you read above
View the full article
I will outline what my understanding of everything I have read about ADO.NET till this point allows me so, I would very much appreciate corrections and insights into anything that sounds incorrect, redudant or should be enfasized. I am explicitly leaving
some points in bold when I would like some better foundation. So here I go:
ADO.NET is nothing more than a collection of objects/components - a database access API - to provide us the most used mechanisms (perhaps there are no other options?) of accessing data stored in databases.
Depending on what you want to do - as always - you make use of the appropriate components of the API.
a) If you want to build commands fully and independently in the client side ( perhaps a reason to choose this one is Batch/offline processing? ),
a connection and a command object are everything you need - as far as I understand. (Here I would like someone to clarify, besides whether what I have just stated is correct - if there is any reason to use a SqlDataAdapter in such cases. I
have been making DML (inserts, specifically) simply building the command object appropriately and having it executed.
My understanding says SqlDataAdatper is useful when working with DataSets, and does not offer any exclusive feat that I may lack in a command object - if I am not working with DataSets ).
b) If what you want is to manipulate the data in-memory - instead of these manipulations being made in the database server (say... any sort of (business) logic that you do not want it made in the server side), then you are better in picking a DataSet
object and a SqlDataAdapter to work with. (although not much clear as to why...
does it build DML commands automatically, based on some definitions you provide when creating the DataSet, and - since the dataset has as one of its features knowing how to keep track of any changes made to the source data from the time it was loaded into memory
- you are free of having to write the corresponding DML statements to update the database and all you have to do is call Update from the SqlDataAdapter object? )
c) If yet you have a different need - you wish to work/think on a different model/representation of your data, other than the one existent/present in the database - you can that resort to the Entity Framework. There, you can create a new model of representing
the data of your business, on the top of the one in the database - that will reside/exist only at the .NET side - and working with the proper Entity Framework objects (object context or the entity container, to mention a few (again from what I understand!))
you have the benefit of all the coding required for connecting and communicating between this new model and the "real" one, that exists in the database - being done automatically by the EF API. If I am correct, then I owe this understanding solely to Google/MSDN,
because the course gave the impression that we would always/only use the Entity Data Model to create a visual representation within .NET of our database model. This, ultimately, does not justify at all developing a new component for ADO.NET and all the
fuss around it. I am assuming that this impression passed in this course definitely does not touch the reasons why the Entity Framework was developed in the first place (and which hopefully I figured out...)
So, if you reached this part of the "question", thank you for your willingness to help (and perhaps even to sharpen your understanding, which is what happens when we have to teach others and face their questions, which may not always be ours) - and please
share whatever insights you may have about anything you read above
View the full article