|
The general rule is, only catch an exception at the point at which you can do something with it, so if you can deal with it at the DAL, then that's perfectly fine. If you need to infrom the user and let them make a choice, then you should throw the exception back up the chain. As always, there are exceptions, but this is a good rule to start with. Ultimately, your decision is going to be driven by what satisfies your criteria.
|
|
|
|
|
Truth is, my thinking is this...
FK's should not be a problem, as the UI won't allow the user to send data to the BLL/DAL with an invalid FK selected.
So if I'm not going to handle exceptions in the DAL, which is probably gonna be the case, then any point in putting in try/catches in the DAL & BLLL at all? If my UI wraps calls to the BLL in try/catches, then I ought to be ok.
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: What's the right way to handle all this.
Log everything you don't expect.
Kevin Marois wrote: I'v heard people say "Handle these issues in the BLL", while other folks seem to think exceptions related to data should be handled in the DAL?
Let's leave the religious argument where it "belongs" to the architecture-astronauts, and stay practical.
The user is usually the one that handles the exception if it's not something that can be ignored or retried automatically. In the case of a FK-violation, the user could be informed and asked to select some other value. In the case of a connection-problem, timeouts, whatever, there's* three retries, and if those fail, there's a dialog with common causes for that particular exception, and the option to retry (Y/N/C). Yes, that's a lot of bubbling-up that an exception has to do from a DAL 
Anything the user can't handle, will be hopefully be handled by a helpdesk, or the author of the software. That's why I included the superfluous advice to log everything you don't expect.
--
(in the ideals situation)
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Exceptions should be handled where they make sense. That's generally in the business logic, because you don't know enough in a data access method to know what a proper resolution is. However, it can make sense to catch and rethrow a new exception, if the exceptions you receive in data access are specific to the data source you're connecting to, because the whole point of layered design is that the logic layer is insulated from the actual data source, so you don't want to be leaking SqlExceptions up to it.
The logic should be designed so that 'obvious' failure cases never get to the DAL, though. In this case I'd expect a user name to be checked for existence before trying to add it, because that's a nicer time to get a message so the user can fix it. And I'd expect the company and role to be picked in a constrained way so the FK can't fail in normal circumstances. DAL methods should only fail if something unexpected happens (e.g. database goes down, race condition between clients causes the data to no longer be valid, etc). The DAL should still handle failure gracefully but it shouldn't be common.
And yes, I'd throw an exception if the user existed, though I think I'd do that just by assuming it doesn't and letting the INSERT fail in the case that it does. Note that your current code can still fail if someone else INSERTs a user with that name between your check and the addition! You might as well just try the addition and let it fail, since you have to protect it anyway.
|
|
|
|
|
0) Yes, you probably shouldn't need to be concerned about referential integrity if the user is selecting items from lists of existing items.
1) If there is a unique index, then I wouldn't check to see if the user exists, I find it wasteful because the INSERT will do this anyway.
2) I prefer to catch Exceptions and wrap them in more-meaningful Exceptions (ReferentialIntegrityException, TimeoutException, etc.) so the next higher level has more information.
3) If there is a user, you should alert him about the issue. If, not, then log it. This is handled by the highest level, not the lowest or anywhere in between. The DAL and BLL shouldn't need to know whether or not there is a log or a user. Consider that there could be multiple client applications using the same DAL and BLL -- some interactive, some batched, maybe a Web Service.
4) I also question the choice of having a Company field in the User -- I'd prefer to have a relationship table to associate them, but that's just me.
|
|
|
|
|
Hi
I use System.Io.Ports and the serial interface to receive data in a Terminal like application. From the .Net driver I have a
DataReceivedHandler where I receive call with each small part of information sent on the serial.
the problem: I have seen sometime some "garbage info", data from previous read. I suspect the call come realy fast and it happens sometime to get old data.
intention:
I want to change my current implementation in this DataReceivedHandler to write in a circular list. This list I intend to be a vector where I put struct having 2 fiels:
- a State bit or boolean flag
- and the information
When I write I just check the state bit (which is similar to a lock), and if it is still false I write the info and increase the indexWrite.
and now the question:
Whould be safe this implementation without using lock{ circularList } when I receive very fast calls to the DataReceivedHandler?
george
|
|
|
|
|
Probably not - IIRC none of the .NET Collections are intrinsically thread safe, and they should all be locked.
Either use the .NET Queue[^] with a lock or homebrew a safe version. If you are just using a single in-feed and a single out-feed, you don't need to use locking if you write it correctly.
One way is to use an array, with two indexes - input and output. If insert only affects the input, and remove only affects the output, the only time they need to both be checked is for a full/empty test, which shouldn't need a lock - it would if you used more than one input source, or more than one remover.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: IIRC none of the .NET Collections are intrinsically thread safe
Actually, .NET 4 introduced the System.Collections.Concurrent namespace[^], which includes a ConcurrentQueue.
However, IIRC there's the potential for a delayed garbage collection - the queue keeps a reference to the object even after it's dequeued until it's been overwritten in the queue's buffer. This becomes more of an issue with a large-capacity queue. Our workaround was to use the Mono implementation of the ConcurrentQueue instead (it doesn't have this problem).
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
|
|
|
|
|
Didn't know that - have a five!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: thread safe
New in .NET 4, http://msdn.microsoft.com/en-us/library/dd997305.aspx[^]
[Edit]
Never mind. OP already posted that.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
yes this was my intention to have to indexes one for read, one for write,
and because it is in a Handlerfunction it should be executed very fast so I will use a vector - as the circular list (or Buffer).
I will try this solution first, after the other with the Thread safe collections.
thx
|
|
|
|
|
probably I need some kind of lightweight lock, bacause the call to the Handler can come realy fast and mess up with my array index, which is already done in ConcurrentQueue<t> Class.
Even if I use a state bit on every element the index could be messed up by another call just before it is used.
I have been wondering how it is implemented.
Would be possible this class: ConcurrentQueue<t> Class to e implemented using just Interlock class
witout any SpinWait or while loops?
modified 31-Jul-12 6:46am.
|
|
|
|
|
how to create monthly calendar in c#?
|
|
|
|
|
|
plz give me appropiate answer.
|
|
|
|
|
sutapa das wrote: plz give me appropiate answer.
I'm not sure but maybe this link can help you. 
How to create your monthly calendar.
Moreover, you don't have to post the same question to get your answer faster.
It won't work here.
|
|
|
|
|
Why not just use one of these[^], or one of these[^].
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Well, how "appropriate" the answer is depends entirely on what the hell you mean by "create monthly calender".
That could mean anything! Are you trying to come up with a control that lets you input a date, a data range over months, something to display an entire month, storing data based on some month requirement, ... ??? WHAT?
|
|
|
|
|
Hi,
Is it possible to make a shortcut in application level not control level so no matter where the focus is or which form is active, shortcut will be invoked?
|
|
|
|
|
You can use the PreviewKeyDown event to see what key is pressed at the Form level.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
As a side note to your answer you also need to set the KeyPreview property to true for the form.
|
|
|
|
|
Shortcuts generally work whichever control on a form has focus, unless the control explicitly steals that character (i.e. text boxes with Ctrl+C/X/Z/V). I think you need to put a shortcut handler on every form, though, if you want app-wide ones.
|
|
|
|
|
Yes, it is, but you will have to go on treacherous ground to do so (needs some unmanaged code). Take a look at keyboard hooks, more specifically RegisterHotKey and UnregisterHotKey, both from user32.dll.
Google it further, there are a lot of threads detailing how this can be achieved, for instance here[^], or here[^]
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
If your application has an MDI form, you can create a menu item with the intended code and assign a shortcut to it. It would work "universally" in your entire application.
|
|
|
|
|
Hello
Does anyone have already experienced the BeginGetResponse illutrated in the Microsoft example ?
http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.begingetresponse.aspx[^]
My need will be to make an hrttprequest in asynchronous mode. To not let the user wait for a response that can be processed in backround.
First I was thinking to use a BackroundWorker, then I see that begingetresponse example
But it react exacly as the BeginResponse : when I step over it wait a few seconds to get the response.
So maybe I misunderstand something but I don't see any advantage of this method ??
Thank for your help
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
