3

Hi I am quite new to WPF. I like the MVVM (Model-View-ViewModel) pattern. My current project has the following type of file/namespace structure:

  Clients
    Controls
      ClientNameControl.xaml
      ClientSurnameControl.xaml
    Views
      ClientCapture.xaml 
    Models
      Client.cs
    ViewModels
      ClientViewModel.cs

And so forth. With each domain object like clients, products etc. each having the structure above. Controls are used to compose views, very generic controls are split out into separate control projects and referenced in the project. My question is if this is a useful structure? All the examples of MVVM seem to take the following approach to file/namespace hierarchy:

  ViewModels
    ClientViewModel.cs
    ProductViewModel.cs
  Models
    Clients.cs
    Products.cs
  Views
    CliewntView
    ProductView

Any comments would be appreciated. Thanks in advance :)

UPDATE: I have been looking around and the below links provided useful information. I am going to structure my project the more traditional way.

akjoshi
  • 15,374
  • 13
  • 103
  • 121
Johan
  • 1,189
  • 3
  • 15
  • 28
  • 2
    I think this post might be closed for being subjective. There's not a real answer to this question. I think your structure can be useful if it works for you. You might get into trouble if a situation arises where you have a control/view/viewmodel that doesn't fit one particular domain object. – Peter Aug 30 '10 at 08:36

1 Answers1

2

We have created different projects for View and View models. It makes things easier to maintain in case of huge projects. Directories we had were -

 - ViewsRoot
    + Base
    + Controls 
    + Documentation 
    + Forms(Windows)
    + Reports
    + Resources 
    + Themes 
    + Utilities 
    App.xaml

 - ViewModelsRoot
    + Collection
    + Commands
    + Converters
    + Resources 
    + TemplateSelectors
    + ViewModels
    + Views (Interfaces for views) 
    Constants.cs 
    Utility.cs

Also have a look at this SO question for some more info. related to WPF project structures - Recommended WPF Project Structure?

Community
  • 1
  • 1
akjoshi
  • 15,374
  • 13
  • 103
  • 121
  • I know, it's an old question, but why do you need Views in ViewModelsRoot? Usually (if you are using MVVM) you bind the VM as datacontext to the view. So the VM doesn't need to know anything about the View?! – basti Sep 14 '12 at 06:15
  • @chiffre This is used in case you want to have a way to call some code in your view(UI specific which can't be done in VM); you may not call it perfect MVVM but in some cases it works. If I remember correctly we used it for displaying the messages(error/warning/info) to user using a custom messageBox(only ViewsRoot) had reference of that. – akjoshi Sep 14 '12 at 12:47
  • Although I haven't used this approach after that it worked well at that time; a related post from that time - http://stackoverflow.com/questions/3670629/should-a-viewmodel-in-mvvm-reference-the-view?rq=1 – akjoshi Sep 14 '12 at 13:00
  • Well this Interface-story made me think about creating an Interface for the VM/V-Binding-Properties and Commands. so you can relay on have it correctly implemented.. ..but maybe this would be overkill... – basti Sep 14 '12 at 13:59
  • Yes I agree, that's not worth the investment. – akjoshi Sep 14 '12 at 14:12