Prism 4 WPF App - Solution Architecture with MVVM, Repositories and Unit of Work patterns implemented

Question

I'm new to .Net and trying to learn things. I'm trying to develop a Prism4 WPF app with

1. Visual Studio CSharp 2010 Express Edition,
2. Prism v4,
3. Unity as IoC,
4. SQL Server CE as data store.

I've studied a lot(?) and infuenced by this and this among others, and decided to implement MVVM, Repository and UnitofWork patterns. This application will be a Desktop application with a single user (me:-)

So, I've created a solution with the following projects:

1. Shell (Application Layout and startup logic)
2. Common (Application Infrastructure and Workflow Logic)
3. BusinessModuleA (Views and ViewModels)
4. BusinessModuleA.Model (Business Entities - POCO)
5. BusinessModuleA.Data (Repositories, Data Access (EF?) )
6. BusinessModuleB (Views and ViewModels)
7. BusinessModuleB.Model (Business Entities - POCO)
8. BusinessModuleB.Data (Repositories, Data Access (EF?) )

My questions are:

1. Which projects should reference which projects ?
2. If I implement Repositories in 'BusinessModuleX.Data', which is obvious, where should I define IRepositories ?
3. Where should I define IUnitOfWork and where should I implement UnitOfWork ?
4. Is it ok if I consume UnitOfWork and Repositories in my ViewModels ? Instict says it is bad design.
5. If (4) above is bad, then ViewModel should get data via a Service Layer (another project ?). Then, how can we track changes to the entities so as to call the relevant CRUD methods on those objects at the Service Layer?
6. Is any of this making any sense or am I missing the big picture ?

---

Ok, may be I've not made myself clear on what I wanted exactly in my first post. There are not many answers coming up. I'm still looking for answers because while what @Rachel suggested may be effective for the immediate requirements, I want to be careful not to paint myself into a corner. I've an Access Db that I developed for my personal use at Office, and which became kind of a success and now being used by 50+ users and growing. Maintaining and modifying the access code base has been fairly simple at the beginning, but as the app evolved, began to fall apart. That's why I have chosen to re-write everything in .Net/Wpf/Prism and want to make sure that I get the basic design right.

Please discuss.

Meanwhile, I came up with this...

Answer 1

First off, I would simplify your project list a bit to just Shell, Common, ModuleA, and ModuleB. Inside each Project I'd have sub-folders to specify where everything is. For example, ModuleA might be separated into folders for Views, ViewModels, and Models

I would put all interfaces and global shared objects such as IUnitOfWork in your Common project, since it will be used by all modules.

How you implement IUnitOfWork and your Repositories probably depends on what your Modules are.

• If your entire application links to one database, or shares database objects, then I would probably create two more projects for the DataAccessLayer. One would contain public interfaces/classes that can be used by your modules, and the other would contain the actual implementation of the Data Access Layer, such as Entity Framework.

• If each Module has it's own database, or its own set of objects in the database (ie. Customer objects don't exist unless you have the Customer Module installed), then I would implement IUnitOfWork in the modules and have them handle their own data access. I would probably still have some generic interfaces in the Common library for the modules to build from though.

Ideally, all your modules and your Shell can access the Common library. Modules should not access each other unless they build on them. For example, a Customer Statistics module that builds on the base Customer module should access the Customer module.

As for if your ViewModels should consume a UnitOfWork orRepository, I would have them use a Repository only. Ideally your Repository should be like a black box - ViewModels can Get/Save data using the Repository, but should have no idea how it's implemented. Repositories can get the data from a service, entity framework, direct data access, or wherever, and the ViewModel won't care.

I'm no expert on design architecture, however that's how I'd build it :)