WPF PRISM modular design

Topics: Prism v4 - WPF 4
Jan 5, 2013 at 3:22 PM

Hi folks

I'm working on an application, have started down the PRISM modular path using Unity for DI and Entity Framework Code First approach for entity/model creation and use. My question is related to modular design concept and where parts fit.

My application is for managing patients in small health care practices. 

I have created a WPF application with Shell window, UnityBootsrapper; also a Client module with a structure of:

  • Views  containing Usercontrols for displaying/capturing input
  • ViewModels containg logic for views
  • Interfaces I currently have nothing in these but are there for dependency injection
  • Model contains my entity structures
  • Data holds my Client dataContext and initializer

The application will allow a client/patient to be entered. A client can have many referrals from different sources and a referral can have many appointments. 

At present my model folder has all the entities I have identified so far for my application but these are not all client specific as I have a referral entity which I believe should be contained in a Referral module? as well as Appointment specific entities that I think should be in an Appointment module. Where would you place all your entities? Also I am about to start creating a referral module, seeing as a Referral must have a Client, how would my referral module be aware of client/patient data, would the Client module have a Search method returning a client that the referral module can call upon?

I've gotten in a bit of a muddle with how architecture should look and how modules would interact with each other?

Thanks for any help.

Developer
Jan 7, 2013 at 6:18 PM

Hi,

Usually modules are decoupled from each other thanks to the use of interfaces. However, this might not be completely applicable with models, specially if you are using Entity Framework as most models are related to each other.

In my opinion, I would move all the models (Clients, Referrals, Appointments, etc.) to a separate project. This project would not be a Prism module but a common .NET project that could be referenced by the corresponding modules. For example, the application could be structured like this:

  • Shell - Has a reference to Models with CopyLocal = true.
  • DataAccessLayerModule - Has a reference to Models with CopyLocal = false. It could export services to interact with the DB and populate models.
  • ClientsModule - Has a reference to Models with CopyLocal = false. It contains the views/view models regarding clients, etc.
  • ReferralsModule - Has a reference to Models with CopyLocal = false. It contains the views/view models regarding referrals, etc.
  • AppointementsModule - Has a reference to Models with CopyLocal = false. It contains the views/view models regarding appointments, etc.
  • Models - A simple project (not a Prism module) containing the Models used in the application.

Like this, the Models can keep their relationships between each other inside a common project referenced by any module that needs them. However, take into account that this is only a possible approach and you might need to structure your application differently depending on the requirements of your scenarios or according to your personal preferences.

I hope you find my opinion useful,

Damian Cherubini
http://blogs.southworks.net/dcherubini