CODEWITHSUNDEEP
wpfmvvmarchitecturestructure
Eido95
Eido95

Reputation: 1383

Is it correct splitting one project into two independent MVVM sub-project

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:

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

Upvotes: 3

Views: 911

Answers (3)

Claudio P
Claudio P

Reputation: 2203

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.

Upvotes: 2

adminSoftDK
adminSoftDK

Reputation: 2092

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.

Upvotes: 2

goobering
goobering

Reputation: 1553

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.

Upvotes: 4

Related Questions