Windows Forms application “design”

Question

I'm planning on writing a "medium-size" WinForms application that I'll write in C#, .NET 3.5. I have some "generic design questions" in mind that I was hoping to get addressed here.

1. Exception handling in general. What is the best way to handle exceptions? Use try/catch blocks everywhere? this ?
2. Localization. If I'd want to have multiple language support in my application, what should I use? I find the "satellite assemblies" to be a very... well, "bulky"-seeming solution - I don't want a resource file "hell", and I don't want to input translations inside the VS UI.
3. Storing data locally. Previously, I've used System.Data.SQLite on a project, but I found myself wondering if there's something else I should consider.
4. Anything else I should keep in mind?

Thanks(?)

Answer 1

1) Don't catch any exceptions. The vast majority of them tell you about a bug in your code, you'll want to know about them right away. If during testing and deployment, you find error conditions that you think you can handle (there aren't many of them), you can always add the try/catch block. If you plan on handling exceptions, be sure to liberally sprinkle try/finally blocks in your code so the state of your classes is preserved even if there's an exception that prevents cleanup code from running. There is no notable cost to using try without catch.

2) Satellite assemblies are not bulky. Just a small DLL in a subdirectory of your deployment folder. No special code is required, everything is automatic. Most of all, it is a standard solution. You can send your .resx files to a localization service and they'll use standard tools (like Winres.exe) to provide you with the translations. Asking them to deal with something custom is going to be expensive and potentially troublesome.

3) Alternatives are SQL Server CE (same approach as SQLite) and SQL Server Express. The latter gives you the most bang for the buck, but must be installed. That isn't hard.

4) It depends on your target audience, but if look-and-feel is at a factor in a buying decision at all, hire a UI designer. S/he'll catch UI bloopers and make it look spiffy.

Answer 2

#1 - If you care about performance of your application , avoid try/catch. Use some profiler for example the one from RedGate (ANTS - it's not a freeware sadly) to see for yourself that try/catch block consume a lot of CPU time , especially if there is a need to jump into "catch". Just try to find any other way around , .net has got a lot other methods you can use to make shore that no exception will occur, I know it's easier to use try/catch but decide what is your aim.

#2 - I guess that you can use resource files that are compiled with you application so you won't have any separate file if that is what you're asking ?

#3 - I really have to answer that one :) , personally I think there is no better/more comfortable way of storing data locally than to use XML , as it was mentioned before, you can use LINQ to XML to query this file , which is extremely simple. It's small , fast , easy to create , maintain and what's more important you can send it trogh the Internet without any problems that may occur using other ways of storing data , example - firewall or any ISD won't be a problem because it's basically a text file. I simply love xml.

Was that helpfull ?

Answer 3

Regarding first question - have a look at Enterprise Library Exception Handling Block. Microsoft did a great job at providing documentation and code to solve this problem.

Regarding other question (especially #4) it is hard to recommend something without knowing details of your application.

Answer 4

I pretty much have the same answer as aku for the first question, you might want to take a look at the Enterprise Library in general since there are several useful blocks such as the Logging and Validation blocks.

Can't help with the second since I haven't worked on any projects that needed to support localization of any kind.

Without a better idea of what kind of data/application you are developing it is kind of difficult to recommend local data storage. A couple of thoughts that I have (no particular order) are:

1. An Xml file is portable and can be manipulated with LINQ->XML.
2. Are your objects stable? You could always serialize them.... (Although I don't recommend this)
3. Although local now, would the data (some or all) be better shared on a server with other users in the future.
4. You mentioned SQLite, have you considered SQL Server CE?
5. What kind of query performance does you data layer need to support?

Answer 5

1. As mentioned before, Exception handling block
2. Not done much localizaton, but the resource handling in VS 2008 is much better than VS 2003
3. SQL Server Compact Edition , VistaDB and Codegear Blackfish are product that you might investigate. SQL CE is free but the others cost money

Answer 6

Why not download Visual C# 2005 or 2008 Express Edition? Designing is easy

1. Open Visual C#
2. Open Create
3. Open Create Project Dialog
4. Design it
5. Code it
6. Publish it

Download 2005 ->

Download 2008 ->