Model-View-Presenter framework: In which project should the interfaces live?

3
votes

I'm dabbling with the MVP design framework, and I currently have my solution set out as follows:

Project: MODEL Contains: Concrete object class, DataRetrieval class, IDataRetrieval interface

Project: PRESENTER Contains: Presenter class, IView interface

Project: VIEW Contains: View class, Program class

I've been revisiting this solution when I can, but now I can't remember why I've got the interfaces distributed as they are. It doesn't seem right. I tried the following:

  1. Move the interfaces into the relevant project for the classes that implement them.
  2. Move both interface to the presenter class.

Making either of these changes is going to require a little work, so I just wondered if either answer is better than the other (or perhaps both are very, very wrong :))

If it matters, this is designed in C#.

I'd love to hear your opinions!

Andy

2
c#interfaceprojectmvp
There is nothing wrong with the way you've described your current layout. Placing the View interfaces with the presenter classes avoids a circular dependency between the presenter and view assemblies. This is a very common approach to project structure in MVP. – Lee Hiles

2 Answers

2
votes

Im just done with my custom MVP framework on Winforms. From my experience I can clearly identify the following sub-projects for any MVP implementation

  1. Model Project
  2. View Interfaces Project
  3. Presenter Interfaces Project (It can sit along with the view interfaces as well)
  4. Presenter Implementation Project
  5. View Implementation Project (This is where your Winforms/WPF/ASP.NET stuff goes)
  6. Application Controller (This is an important and often overlooked aspect of the MVP. It is responsible for starting the entire framework including the application itself. It also manages cross presenter communication and navigation)
  7. Application Navigator (The navigator dishes out the concrete views and presenters when demanded by the application controller)
1
votes

I would like to suggest you add a separate project to your solution and call it YourSolutionName.Contracts. Move there all your View and Model interfaces, so your Presenter project won't have dependencies from these two assemblies (for more details check dependency inversion principle).