3

I am currently working on a big WPF project which is already been developed and structured, furthermore it is expected to grow. However it doesn't have any of the MVVM pattern architecture components.

One of our goals now is to restructure contained UIs to support the MVVM pattern components.

Due the design of MVVM view layer development separation, removing virtually all UI "code-behind", we raised the above idea.

The above idea takes advantage of the restructure to future development, so we consider to split the current project to two:

  • UI Project - contains and manages present and future UI codes (Views and ViewModels).

  • Logic Project - contains and manages present and future logic codes (Models).

Is it correct to apply such splitting? will it be overkill for future development, debug and testing?

Improve this question
1
  • Hey, we use prism and we have our views and viewmodel split into 5 separate projects, not to mention other projects (infrastructures, data layer etc). We use prism to manage them those 5 (4 of them are prism modules - wpf class libraries) and one of them is the main wpf project which loads the others into a shell. Commented Apr 2, 2015 at 8:07

3 Answers 3

Reset to default
4

I don't see any problem in what you're proposing. If you follow the MVVM pattern 'correctly' then it should provide complete separation between your Views and your ViewModels. As such it might also make sense to put all of your Views in a separate project to your ViewModels. Your ViewModels should all function perfectly well without Views, giving you a really clean separation between UI production tasks and logic production tasks. Your Views can make use of design time data to simulate the behaviour of the ViewModels without actually having any logic present.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I am continued to develop by your answer with three independent projects (View, ViewModel, Model).Your idea gave me a complete separation so that if i accidentally writing View code inside ViewModel class that might break the MVVM pattern, It won't happen and I will get compile error because my ViewModel project doesn't actually have the suitable references to the View code. Thank you very much for your answer.
2

we use prism and we have our views and viewmodel split into 5 separate projects, not to mention other projects (infrastructures, data layer etc). We use prism to manage those 5 (4 of them are prism modules - wpf class libraries) and one of them is the main wpf project which loads the others into a shell.

Improve this answer

Comments

2

It is a very good idea to split the business logic into another project, which will be built into a DLL. After this you can reuse all the business logic in another Frontend Application (for example a Web project). After this you can take advantages of the MVVM pattern to replace the Frontend part and reuse the logic part.

Future development

It's better for future development to split the projects, because changes on the business logic can be made without touching the UI project.

Debug

The debug tools today can handle this without any limitation.

Testing

Normally you can do the same split for testing. If you make Unit Tests for all the functionality in the logic project everything is covered except the UI.

This means, splitting the projects is always the better choice.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.