Printable View
I believe it is best practice to place code to connect to your database in a separate thread. While this is not crucial, I think it makes for better user experience. My boss is telling me there is never "[Any] point" to it. I think she does not know what multithreadding is.
What do you think?
ALSO: Do you know of any msdn "best practices" documentation that addresses this?
Thank you!
What advantage do you see by putting the database access code in a separate thread? Are you trying to separate the data from the UI or something else?
Arjay
No. It simply keeps the main thread from being blocked, allowing the user to continue to manipulate the window they are working in (min, max, resize, move, etc.). It also allows for the main window to repaint itself properly while waiting for the connection to complete or fail.
Never heard or thought about this idea. I have worked on projects implemented with the multiple tiers architectures.
Got something new to hear from you but I guess this is gonna create a lot of complexities and also the usual threading related obstacles/issues would appear more frequently. Until you have a sound and clear thought about its implementation I wont go for it.
I would also like to know about the advantages that you would be extracting/exploiting with this methodology. I guess you would try getting the data access commands going while proceeding with the further non-data access related stuff.. but that hardly gonna pay you back in terms of performance..or is it? Plus the added complexities... Nah ..I wouldnt go for it too unless you convince me. :)
Heh I see that it sounds more complex than I wanted to make it. I am simply talking about a) a user starts an application and needs a database connection first. b) the user goes to the menu and clicks "connect".Quote:
Originally Posted by exterminator
The question is, if you had the time to code it "right" would you put the connection code in a separate thread so as to not bock the main thread until the connection completes. This way, the user can manipulate the window and the window will repaint itself while the connection is taking place. The alternative is that the main thread is block and the window just sits that unable to repaint, and unable to be manipulated by the user.
Side note: The point you bring up is kind of what a smart client would have to do. What's that called, "Disconnected Processing"?
Are you talking about just making a connection or even executing DDL/DML too? In that case suppose the user needs to show the updated stuff on the UI (its just a simple example) and now you cannot coz may be that is still not fully executed and a commit trans is yet to happen. One exception case can break the whole concept of the genericity that you are trying to introduce.Quote:
Originally Posted by gangelo
Aaahh yes..forgot about the strengths of ado.net. But anyways, threading wont help one with this either..would it (i mean whats the need?)? If one just want to do this whole stuff for the building of a connection part then its okay..its up to the individual (and of course time as you rightly say in the poll title) ..they can do it...but if they extend this to what I talked about in my last post..it gonna get messy ..isnt it?Quote:
Originally Posted by gangelo
Okay, your intent is to separate the UI from the data. I wanted to be sure you weren't using threading as a method to forceably close non-responding db connections. Using threading as you have described is one of the exact intents of threading (to allow the UI to remain responsive during intensive operations). Threading does increase complexity (although not that much), and in my opinion, can lead to a more professional, polished application.Quote:
Originally Posted by gangelo
Arjay