How would you architect a desktop application in C# 3.0

Question

I've created a simple desktop application in C# 3.0 to learn some C#, wpf and .Net 3.5. My application essentially reads data from a csv file and stores it in a SQL server CE database. I use sqlmetal to generate the ORM code for the database. My first iteration of this app is ugly as hell and I'm in the process of refactoring it.

Which brings me to my question. How would you architect a desktop database app in C#? What are the best practices?

Do you create a Database Abstraction Layer (DAL) which uses the sqlmetal generated code? Or is the generated code enough of an abstraction?

If you use DAL pattern, do you make it a singleton or a static member? Do you use the View-Model-ModelView pattern with the DAL pattern?

Apologies if this seems like a long open ended question, but I have been giving this a lot of thought recently. I see a lot of examples on how to architect an enterprise n-tier app in C# but not that many on architecting standalone desktop apps.

Answer 1

I would start with the Composite Application Guidance for WPF (cough PRISM cough) from Microsoft's P&P team. With the download comes a great reference application that is the starting point for most of my WPF development today.

The DotNetRocks crew just interviewed Glenn Block and Brian Noyes about this if you're interested in hearing more from them.

Even better, Prism is not nearly as heavy as the CAB was, if you're familiar at all with that from the WinForms days.

Answer 2

The answer is "it depends" as always.

A few things to think about: You may want to make this fat client app a web app (for example) at some point. If so, you should be sure to keep separation between the business layer (and below) and the presentation. The simplest way to do this is to be sure all calls to the business logic go through an interface of some kind. A more complex way is to implement a full MVC setup.

Another thing you may consider is making the data access layer independent of the business logic and user interface. By this I mean that all calls from business logic into the DAL should be generic "get me this data" rather than "get me this data from SQL" or even worse "run this SQL statement". In this way, you can replace your DAL with one that accesses a different database, XML files, or even something icky like flat files.

In short, separation of concerns. This allows you to grow in the future by adding a different UI, segmenting all three areas into their own tier, or changing the relevant technology.