10

I am building an application in python with a python wrapper for WPF and with DAG support. I am currently at a point where I have to decide a consistent way of interacting between the data and the view.

As far as I see there are currently two obvious solutions.

First one is similar to how Android Applications are structured. You have a controller which sets/populates the view. So the controller owns the view and pushes only the primitive data that will be displayed. The view is just a dumb layer and has no idea of what's happening and where that data is from. And then if user interacts with the view, it will send callbacks to the controller (if it registered).

UserInfoController.py

userInfoView = UserInfoView()
userInfoView.onGenderChangedCallback = self.onGenderChangedCallback 
userInfoView.setUserGenderValue(user.getGender())

UserInfoView.py

def setUserGenderValue(self, gender):
    self.userGender = gender

def getView(self):
    return ui.Label(self.userGender, onEditCallback=self.onGenderChangedCallback)

Second one is passing a (reference of) model to the view and letting the view to retrieve and update the data. The view now contains the model and therefore it can update it without any additional callbacks to the controller.

UserInfoViewModel.py

self.gender = 'Male'

UserInfoView.py

def getView(self):
    return ui.Label(self.ViewModel().getGender(), onEdited=self.genderEdited)

def genderEdited(self, newValue):
    self.ViewModel().setGender(newValue)

So I guess what I am asking is, should I pass the very primitive data and keep the view as generic as possible, then work with callbacks and do the business specifics in the controller.

Or should I pass the whole model to the view and let the view to update the model directly. This means that there will be less code to type.

PS. Do not judge the code - it's just for visualization.

EDIT:

Also to add - this application will be written in python which supports ducktyping. This means that with the second approach, the view is still reusable as long as the model meeting the required interface.

Arturs Vancans
  • 395
  • 2
  • 9

2 Answers2

3

The only "logic" a view should contain, should be the code responsible for changing the visible state of the GUI to the user. Any code that manipulates data or calculates a value should be handled somewhere else.

Your view should know what the model looks like, but should be ignorant of the behavior associated with any thing the model exposes.

Passing simple data types to your view makes it responsible for both manipulating the GUI and storing the view state, which can easily become unwieldy.

You should pass the model directly to the view if the model is built for manipulation by the view. If your model is the same one used by your data storage mechanism, that can cause problems down the road if your internal representation and view representation diverge (as the often do).

Basically, you should just have a View, View Model, Data Model and something to handle business logic. Then all your concerns are easily separated, you just have to glue them together.

mortalapeman
  • 1,613
  • 9
  • 20
1

This is somewhat a generalized answer, but IMO view should do the least amount of work possible (e.g. validate user inputs).

This way you can expect all your logic to be in controller. This makes it a lot easier to maintain down the road, single responsibility principle, and all that.

Evgeni
  • 451
  • 2
  • 7