sri
sri

Reputation: 23

How would you design business logic interaction with Viewmodel in mvvm

What are the ways where a viewmodel can get business logic. Lets say, I have 3 Models and based those 3 models data I will produce(basically calculation) some new values(lets say model 4) where I will show this Model 4 data in View.

Note I can not put calculation logic on service side because i dont have control..on them. I have to compute Model 4 on my side.. Where should I compute this Model 4 Values?

Questions 1) Is it good practice to call Service form ViewModel i.e GetModel_1_Data,GetModel_2_Data, GetModel_3_Data if not whats the good practice ?

2) As per mvvm I am not allowed to have business logic on ViewModel ...then where should I do? What are different ways we can achieve..this ?

3) In Mvvm I see models consumed by UI basically Models with INotifyPropertychanged .. what is the right word to call them.. can I call as UI Models? or UI model objects? Other Models just like plain CLR objects.

when I read about mvvm many say to keep logic in Model..whic model ..does they mean plain clr classes..or UI models(where they have INotifyPropertyChanged) If not do we need to have some layer to produce UI Models from POCO models? What this layer is called ..if so...

Thankyou,

Upvotes: 2

Views: 2554

Answers (1)

Xiaoguo Ge
Xiaoguo Ge

Reputation: 2328

I think once you stop thinking Model as a single class, everything should clear up. MVVM is all about presentation layer design. In order to focus on presentation, it abstracts the whole business logic layer into a Model. In this sense, Model is a layer instead of a single class or component. It itself can have its own design patterns(services, DDD, CQRS, ...).

To answer your questions

Note I can not put calculation logic on service side because i dont have control..on them. I have to compute Model 4 on my side.. Where should I compute this Model 4 Values?

This depends on what do you think the computation logic is. If it is business logic, then it should be put into the "Model" layer. There is not always a clear line. Sometimes, it is a decision/classification you make.

Questions 1) Is it good practice to call Service form ViewModel i.e GetModel_1_Data,GetModel_2_Data, GetModel_3_Data if not whats the good practice ?

I don't see why not. An alternative is to add an additional Application Service(or Display Service) layer to separate the creation of ViewModels from the ViewModel itself.

2) As per mvvm I am not allowed to have business logic on ViewModel ...then where should I do? What are different ways we can achieve..this ?

As answered above, as long as you think that the calculation logic is business logic, they should be put into "Model". Unless, that Model 4 is pure presentation. An alternative is given above

3) In Mvvm I see models consumed by UI basically Models with INotifyPropertychanged .. what is the right word to call them.. can I call as UI Models? or UI model objects? Other Models just like plain CLR objects.

They are usually called ViewModel

when I read about mvvm many say to keep logic in Model..whic model ..does they mean plain clr classes..or UI models(where they have INotifyPropertyChanged) If not do we need to have some layer to produce UI Models from POCO models? What this layer is called ..if so...

Model can mean business logic objects or business logic layer, in the context above, it means the business logic LAYER

Upvotes: 3

Related Questions