What is a good way of implementing logic validations in MVVM?

Question

I'm using the MVVM Pattern for a new piece of .Net software with WPF GUI. The validations of properties is going well using the IDataErrorInfo, where all the fields light up. However i'm looking for a good way to implement some sort of business logic.

Simple example; If you have a table which contains columns, i'm using the IDataErrorInfo interface to check if the name is not null / valid. But i also want to make sure the column name is unique. Could also be that the column is being used elsewhere so it can't be removed.

Any suggestions on how to implement business logic using MVVM? Have been looking around, can't seem to find 'the' solution.

Answer 1

In my use of MVVM within WPF and Silverlight, business logic is usually implemented deeper in the domain layer accessible via services by various consumers. As far as implementing domain logic in this more abstracted way there are endless options depending on the complexity of your application and how dynamic your business rules are.

Some would say that the validation of domain objects should take place in IOC injectable validation services rather than being baked into the domain objects themselves (unless it is absolutely core, unchanging logic to your domain).

I generally find that approach a bit overkill. You could have your domain objects implement some kind of validation interface which potentially chains validation down through an entire object graph. Domain objects could enlist in sharable business rules either in a baked-in or dynamic fashion, e.g. a rule which checks the state of the domain object and its related objects and adds an entry to a collection of broken business rules.

Answer 2

Location of business logic is always a difficult one when using MVVM pattern. The question is always is it View Model or Model?

I guess it depends on where you're checking for duplication.

If you're attempting to prevent the user from duplicating data that is presented in the View then you would do the checking in the associated View Model.

If you're attempting to prevent the user from duplicating data that is present either within the model or within an associated data layer (read DB) then it should be performed within the Model domain.

The only thing that you need to bear in mind is that your code presents the data to the View regarding the duplication, but it is up to the View to decide whether to present it.

Quite often I place large amounts of business logic and 'helper' functions in a separate class library project and call functionality from where it feels best. This can make it easier to switch functionality from the View Model to the Model and vice versa.

Have you seen the msdn MVVM pattern pages? Have a look here.

Remember, though that as in all things a pragmatic approach needs to be taken. There may be occasions when apparant business logic is placed in View code behind, but it should always be kept to a minimum.

Answer 3

I would like to recommend this book (link to Amazon.com): Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern

Although it just has the MVVM in its title, it gives a wide range of topics and a possible ways to organize and structure applications.

I found a lot of useful ideas and suggestions in it.

The only downside I see is that it is not going too deep into the single topics. On the other hand, you can read it quick and do not necessary need to read each chapter sequentially but concentrate on what you just look for.

The book helps you to get a general idea of what you would like to know and a good starting point where you might go into more depth later.