Tuesday, April 24, 2007
a)Why would you ever catch all exceptions? You should know what exceptions are coming back at you catch specific ones and deal with them appropriately. The only* time I could ever see this being usefull is for logging purposes...
b)Dont hide exceptions... deal with them. Catch exceptions and doing nothing is pretty rank... at least comment the hell out of why you are doing it.
c)Get FXcop or some tool that tells you when there is rubbish code in your solution!
*OK there is probably a few areas, but not as many as some would think...
Friday, April 20, 2007
User Controls are a common way to develop reusable UI components that use a common layout or have common generic functionality. Unfortunately I so often see these controls being developed, in my mind, incorrectly. User controls should generally be dumb. They should know very little of the out side world (except of course of the namespaces they inherit from and maybe utility classes that perform common public static encapsulated method calls). Think text boxes, drop down lists etc. These don't know about your business objects! You passed in and retrieve properties from them. They may do some basic processing however this is generic. They should certainly never call or run business logic or know about services. So how do we use User Controls to run common logic? On the user control there should be publicly visible properties. This is usually a given. There can also be methods and events. Often I call a PopulateControl(Type type) (which is a public void Method) that takes in a control specific DTO (or collection of DTO's). Usually this merely passes each of the properties in the DTO to the properties in the Control. Right, so data is in the control, how do we do stuff with it? The page load may have some generic code, but avoid adding smarts that are too specific. How about passing data back to the parent? Either retrieve the data from a MyDto read only property the does the exact opposite of the populate control returning a DTO or create a custom event eg Save and pass a delegate into the control. Yes this mean code stays on the page. So?? If it commonly called create a class that does all the leg work for you that all page can call. This then follows the MVC pattern and separates the visual aspect from the Data aspects
Question: why do you use PopulateControl(Type type) and RetrieveDTO() and not properties? Answer: I am of the opinion that a property should never be able to throw an exception or call code that can throw an exception. If you are confident that this can not happen then, sure, use the property approach. However, if there is functionality that may cause an exception, then use the method approach. I wouldn't expect people to strictly follow this, this is just my preference.
Question: When to use Delegates? Answer: When it is obvious that this control does something, like its is a control that has customer details for adding or editing then a save delete and cancel buttons may be appropriate. Control of what is done on the User Control (usually the page) with the event (ie EditCustomer_OnSave()) means that page can pass in the correct logic or call to the manager of logic as a delegate. Obviously this means exposing something to apply the delegate to, such as an event!
I am more than happy for feed back on this. I want to do better code, you may be able to help!
Wednesday, April 18, 2007
lessons have been learned
Tuesday, April 17, 2007
Long and short of it, xml site maps have never really sat well with me, i know Gumble has rewritten sitemap stuff before, however the project we are working on is using the xml source (not DB) so i'll stick to it.
Cheers to SteveE for the help on this too.
Monday, April 9, 2007
Tuesday, April 3, 2007
One line synopsis:
Basically don’t use in built AJAX when sensitive data is being passed, but it is fine on public sites.
The two events OnSelectedIndexChanged and OnTextChanged seem to actually check if the value of the dropdown list has changed. When queried what the selected index is it will give you the first value that has the selected value. Basically the OnSelectedIndexChanged is incorrectly named, it should be OnSelectedValueChanged.
Other bugs in this control are .SelectedValue actually returns the lowest indexed listitem with the selected value, and when you would expect .Text to map to the visible text it actually is the corresponding value (so both of these are incorrect in kinda the same way).
Because of this, the OnTextChanged event does actually work "correctly" just not at all intuitively and it appears that it too comes under the nonexistent OnSelectedValueChanged event.
To be honest im a little disappointed that this has persisted through to .Net 3.0, I would love to hear a why this is still the case.
How I have found this (yes i'm sure millions of other have), is a client wants duplicate values with diffent text in a drop down... not sure if there is a real business reason, bu theres the background anyway.
End rant, sorry my firstone was negative... oh well
See you soon :)