how would you architect a desktop application in C# 3.0

Question

Hi 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 dekstop databse 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

Before architecting anything you should define requirements for your app.
It's a common error of beginner developers - starting writing code ahead of thinking about how it would perform. My advice will be to try to describe some feature of you application. It will help you to feel how it should be implemented.

As for useful learning resources I would highly recommend you to take a look at CompositeWPF it's a project designed specifically to teach developers best practices of desktop app development.

Answer 2

No special requirements. My app takes my monthly bank statements and stores them in an embedded database. I can run reports on the data and compare them to my budget. Very similar to Microsoft Money. All the requirements of MS money apply here as well.

Answer 3

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 4

I've come across the Composite Application Guidance for WPF site. I had a brief look at it. My impression is that it was geared towards large teams developing a single application. If I understand you correctly, you saying that it also provides guidance on structuring smaller applications?

Answer 5

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.

Answer 6

I would say yes, it could easily be structured towards smaller applications. There is a learning curve towards getting started, but honestly, it helped me understand WPF better than attempting to start from scratch. After starting a project with CompositeWPF and then starting another project without it, I found myself attempting to duplicate features of CompositeWPF on my own because I missed those features! :)

Answer 7

I'd start with Jeremy Miller's Build Your Own Cab series.

I was an early CAB adopter. I learned a lot from digging into that technology and reading all the .NET blogs about application architecture.

But recently I had a chance to start a new project, and instead of using CAB I went with StructureMap & NHibernate and borrowed some of the patterns that Jeremy uses (in particular, his way of handling event aggregation). The result was a really simplified, hand-tooled framework that does everything I need and I love working with it.

As to the specifics of your question: I use a Repository for data access. I initially wrote some ADO.NET code and used data readers and mapped my objects. But that got old real fast, so I grabbed NHibernate and was really pleased. The repositories use NHibernate for data access, and my data access needs are pretty simple in this particular app.

I have a service layer (exposed via WCF, Duplex channels) that utilizes the repositories. My app is basically client-server with real time updating (and I know your question was just about clients, but I would use the same technologies and patterns). O

n the client side I utilize MVP with StructureMap for IoC and some very simple event aggregation strategies for cross-class communications. I code to interfaces for just about everything. The only other thing I did was borrow from the CAB the idea of a flexible "Workspace" for dynamically displaying views. I wrote my own Workspace interface though and implemented my own DeckWorkspace and TableWorkspace for use in my app (these were really simple things to write).

A lot of my decisions in this most recent application were the result of experience and pain I felt using other frameworks and tools. I made different decisions this time around. Maybe the only way to really understand how to architect an application is to feel the pain of doing it wrong beforehand.