WPF Line Of Business Application Architecture

Question

In my company (for the first time) we're developing a quite large line of business application in C# with WPF. I decided for a UI-modular approach like the one in Microsoft PRISM, but I'm scratching my head on how to develop the business and data layer.

I need to support at least two database: SQL Server for client/server installations, and SQLite for single user installations, but I'd like to be ready for other db or cloud/rest persistence solutions. And in the future we'll likely have to develop a web version and a UniversalApp version!

The solution I'm thinking on is:

• WPFClient.MainShell (exe)

• Other shell dll (bootstrapping, dynamic module loading, ...)

• Company Module:

  • WPFClient.Companies.UI (viewmodels and views)
  • WPFClient.Companies.BIZ (manager objs for validation, calls to persistence layer, ...)
  • WPFClient.Companies.Data (common interfaces for persistence layer)
  • WPFClient.Companies.Entities (entities shared among ui, biz and data layers)

• Workers Module

  • WPFClient.Workers.UI (viewmodels and views for Workers management module)
  • ...
  • WPFClient.Workers.Entities (entities shared among ui, biz and data layers)
• Other modules (ex. Contracts, Visits, ...)

---

Concrete implementations for persistence layer:

• WPFClient.Data.SQLite (concrete persistence layer that references the X.Data and X.Entities dll of one or all modules)
• WPFClient.Data.SQLServer (concrete persistence layer that references the X.Data and X.Entities dll of one or all modules)
• WPFClient.Data.????

---

The references between projects are:

• ModuleX.UI -> ModuleX.BIZ and ModuleX.Entities
• ModuleX.BIZ -> ModuleX.Entities and ModuleX.Data
• ModuleX.Data -> ModuleX.Entities
• ...Data.SQLIte -> ModuleX.Entities, ModuleX.Data, ModuleY.Entities, ModuleY.Data, ...

Of course concrete implementations will be resolved by a ServiceLocator mechanism.

I did not find any example of a LOB application written like this. I read a lot, tons of articles about unit of work and entity framework, CQRS, blah blah blah but all were too much theory!

What's wrong with this architecture? Is there a better solution or a real world example to look at?

Just to be clearer: suppose I have to save a worker with his job history (or the classic example order with multiple orderitems). If the biz layer "knows" it has to save in multiple repositories it would mean that the biz layer knows about the persistence mechanism, so it knows too much. But if the biz layer simply pass the command (SaveWorkerInfo or SaveOrderInfo) to the persistence layer than it's the persistence layer that knows too much and the biz layer only performs validation (I think this is CQRS style).

Thanks a lot, I know it's a long post to read!

Answer 1

I think your initial draft looks good. Take a look at this video for some inspiration for how to organize the structure of your application. In your last question you mention repositories etc and I assumed that you have some knowledge of domain driven design. I seems that you need reconsider your aggregates. Read this introduction to CQRS and you will know that the command will never reach the data layer in your application.