I have been creating applications that use sql queries and stored procedures.
The other way to do it would be to use ADO.nets objects that help you like DataTable,DataRow, DataColumn. I hardly ever use them at all so are they really worth going into in depth. I prefer SQL to do all my data manipulation.Perhaps you should explain how you use sql queries and stored procedures and how you think they're more effective.
I find it much easier to manipulate the data in a db using Sql queires and executing them rather than loading data into a dataset manipulaiting it and the pushing it back to the datasourse.
Can you give us some code? I still don't follow you. We all use queries or stored procedures, and what I don't get is how you're relating them to datasets, datatables, dataviews, etc. in your particular circumstances.
I guess that he is talking about the data adapters ... (data adapter & datasets vs commands or just plain sql)...
No?
Correct.
DataApapters and Datasets vs Command & Sql
Well it all depends on what your specific need is. Obviously you don't use what you don't need. For example you wouldn't create a whole DataSet to bind to a control when all you need is a SqlDataReader.
Perhaps below link could give you little bit biggning for your thoughts on Dataset/reader etc!!
http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconoverviewofadonet.asp
I almost had to wonder when I saw this subject line--has someone created another data access framework for ASP.NET? One that sends queries "straight" to the database without all those "nasty layers" in between?
On skimming it, I see that the real issue isn't ADO, but rather, how much of ADO to use.
This is another one of those questions where I think that the answer is impossible to arrive at until you first define who is going to pay for lunch.
Huh? what does paying for lunch have to do with it? Everything. What I mean is this--almost everything you put into an application is a tradeoff in one way for another. Everything comes at a price--including lunch--and the choice isn't whether or not to "pay the price", but rather, WHERE to pay it.
In this case the issue seems to be, err, umm,,, hmmm... on re-reading it, I still can't figure out just what IS the question. It would seem that someone is concerned that all that Dataset/dataadapter/datareader stuff is too much ... errr... well, again, I can't really tell what they think it is too much of.
But I can tell you one thing all that stuff represents and that is one way of paying for lunch. And quite an elegant way, at that. A way that lets us spread the cost of some things to more appropriate places depending on our application's needs.
Oh, BTW, in this case, the 'lunch' IS the SQL we write to manipulate the database. ADO gives us some really nice choices--do we go the super, dooper econo route--make everything from scratch, spend all day over the hot stove? Or do we save on some areas so that we can focus more on the menu and on enjoying it when it's done? (faster development, fewer buts, easier to maintain, etc...)
But I'm still curious. Has our poster found a way to go straight to the database from a line of code without using anything else? Just write a stored procedure, and then refer to the columns it returns in the app, and leave it to Scotty to beam up the data when it's needed?
Well said Jim,
Personally I like the elegance of the dataadapter/dataset model. I guess some people are just more comfortable working at the plumbing level though. I prefer to leave that to the 'experts' and give myself more time on the Bus Logic and things like performance and security.
Jon.
I think that the guy is just saying that to have to write all those commands in a adapter and then calling is not necesarily better than to write a parametrized query using a command object, etc... or something like that.
It really depends on your coding style I guess... I personally use datareaders for searches (read only views of data) and either custom business entities or datasets when updating or moving stuff around for updating or some other operations.
If it is a small application don't even bother with those questions, its a waste of time & money. Use the simplest way possible.
If it is a small application don't even bother with those questions, its a waste of time & money. Use the simplest way possible.
Good point. But when it is not a small application, that's when things aren't so simple. Then you have all kinds of things to balance -- simplicity (often not an option as an app gets more complex), efficiency, ease of maintenance, etc. Usually you have to end up sacrificing one or more of these to gain another one, and "simplicity" is generally the first virgin to be sacrificed to the "requirements" god.
hehe, nice way of explaining it Jim :-) . I agree with what you said. Long time ago I learned that there is no such thing as a free lunch. What I tried to say by simple is that for instance , you know that your app. will run in an intranet and will only have 50 potential users out of which only about 5 will be connected simultaeously, then the project should even be fun to code!!!, you should not waste time trying to design a super app... just keep it simple. Every question has a "it depends" answer... because when you design an app you have to take into consideration different variables such as time, cost, environment, etc...
I think that what is more important is that you know and understand what your options are and the sacrifices that you will have make (i.e. performance vs maintenance, etc) while designing your application. I think that sometimes people try to design the perfect solution and while doing that they start lose focus in what is important. There are plenty of examples on how to do the things the right way out there, a full menu of options, just follow the approach you like to most, and even more, create your new dishes...
0 comments:
Post a Comment