Exploring a WPF Business Application Architecture 1

I've been spending some time looking into how to easily build WPF based line-of-business applications lately. To illustrate my thoughts on that subject I'll put together a sample based on the time honored Java Pet store. In this post I'll write a bit about the type of application I'm aiming for, the pet shop, and the architecture I'm aiming for. In a series of following posts I'll show how the domain model, the persistence, the presentation and so on are coded.

So, I'm not trying to figure out how every WPF app should be architected. Far from it. I'm trying to figure out a default architecture for moderately sized business applications. I.e. apps that: Use WPF for presentation, use an SQL Server database for persistence, runs on an intranet, has in the order 100 - 200 unique users, has moderate to large amounts of data (not huge, though), and no special security issues.

To illustrate I'll use a pet shop: The users can browse through categories of pets, put them in their shopping cart, and eventually check out and pay for the pets.

The plan is to use the MVVM pattern which is a variation on MVC, that focuses on allowing for use of WPF's 2-way data binding while still allowing for separation of concerns. The domain model is nicely separated from the view by the view model, which adapts the data in the domain model to the needs of the view. The presentation logic is pulled out of the code behind files to keep it separated from the view itself. All-in-all MVVM delivers a nice structure that allows for good testability and maintainability. To implement this part I might use Caliburn or PRISM or I might do it by hand. I haven't decided yet.

For the persistence of the domain model to the database I'll use Castle.ActiveRecord which is build around Fowler's Active Record pattern: Each domain object is responsible for its own persistence. Each domain class maps to a database table and has CRUD operations. Each domain object corresponds to a database row. Castle.ActiveRecord makes it really easy to use the Active Record pattern: You just have to add a few attributes to the domain classes and their persisted fields and off you go. Your domain objects are still POCOs except for the attributes, so you get to keep your domain object clean and almost-free of infrastructure.

Lastly I plan to throw in Castle.Windsor for dependency injection.

That's it for now. Next post will be about the pet shop's domain model, and about persisting it through ActiveRecord.