Suppose, I am creating a barrister manager using ASP.Net and CS.

My aspx page contains the form which collects details of barrister. Then there is a data grid which displays all barristers in database.

My code behind page can do the add / edit / delete operations in 2 ways.

1) I can create a connection object and command object. Then I can create the insert / update / delete query out of the values posted. (May also use stored procedure and send posted values as parameters). Then I can use the ExecuteNonQuery method of command object to run these queries.

2) I can create a data adapter and a dataset. Then using the AddRow, DeleteRow or Updaterow methods of adapter object, I can add data.

My doubt is which method is better and more professional ?

Why there are two methods ?

My take on this subject is that WebForms favors one way while WinForms favors another. Although I'll make the disclaimer that I do not work with WinForms regularly and my opinions are based on what I have read in articles and in questions on this board.

When I'm in WebForms, most of the time I make database update calls with Command.ExecuteNonQuery(). This seems most logical to me because WebForms is working with stateless data. Depending on the scope of my data retreival code (is it in the webform code-behind or a data access layer) I will use either the DataAdapter/DataSet or Command/DataReader. Seeing as most of the time in webforms you are making one-off data hits to the database it makes more sense to use small clean queries with the ExecuteNonQuery method instead of setting up all the objects for a dataset Add/Delete/Update.

On the flip side, when working with a WinForms application your data is stateful because the program is 'living' in memory (versus the statelessness single-page execution of webforms). In this scenario it would seem to make more sense to work with your data in a disconnected (but stateful) nature and use the Add/Update/Delete functionality that you can take advantage of in a stateful application.

I doubt that either method you describe is any better or more professional than the other. However, as most techniques in programming go, one has a more suitable use than the other depending on the scenario, and what's more professional is knowing which one to use.

-Peter

Hello Planoie,

Thanks for the reply.

I am new to winforms. I have not used it anywhere. I think, it is to be used in VB7. Can I use a winform in a web application ?

Not natively. Hence the names WinForms and WebForms. If you build a completely HTML based application in ASP.NET, you have to use WebForms only.

The line between windows (desktop) applications and web (browser based) applications is going to start getting very blurry. You can have a web "based" application that actually downloads windows forms that talk to web services so you have a richer client experience but still have a web "enabled" application.

-Peter

Hi to all.

I my opinion, the data adapter / datset combinantion supports what we call disconnected database model. This model is suitable for distributed databses where not only database is fragmented horizontally or vertivally but the no. of users of application are variable at a given point of time. Although concurrency is a major issue and cannot be ignored.

The second model ( command / connection) is suitable for either desktop applications where database and front end are on same system or it is suitable for a limited multiuser windows application.

As far as asp.net is concencerned, i do support the notion of stateless nature of pages and obvious use of command/connection objects directly.

Any commnets?

Cheers.

Anubhav Kumar

Thanks for the replies Planoie and Anubhav.

I think, winforms are similar to active x controls on browsers (managed active x control ?). I fear it is not compatible to browsers other than IE. Is it correct ?

Madhu,

If Feel you should spent some time on .NET Data Access Architecture Guide
(http://msdn.microsoft.com/library/de.../html/daag.asp)

and also think about whether use Microsoft Data Access Application Block for .NET, because it will reduce a good no of Lines of code.

Thanks Prashant for this great link. It gave me a lot of ideas.