Think of an inventory management system.
Imagine the user scenario of creating a new inventory item.
This is implemented using a wizzard-like UI.
First step: The user is told to enter some limited but basic information that he knows about the new item.
Next step: The system takes that key information, and looks if there already are similar items in the inventory. The user is shown the resultlist of that lookup. The user can then decide to go on creating a new item by entering more required data on subsequent steps, or leave the creation process by picking an existing item from the resultlist of matching inventory items. Note that the list is only used to enable a human interaction at that early point in the process.
I have an ItemCreator editable root class that is responsible for the process of creating a new item.
The point where I am struggling is whether the resultlist of possibly matching items should be a property of the ItemCreator class or be better located as a property inside the ItemCreatorViewModel class.
What do you think?
Any hints are greatly appreciated.
If you set the resultlist as a property on your view model, you can then bind to it with your list control with ease. Using Property Change events, it will also automatically change the list in the control whenever the criteria is changed.
Thanks for Your answer!
That is the way I have actually implemented it.
What keeps me confused, is the fact that my ItemCreator object knows nothing about this intermediate step involving the lookup...
Isn't that business logic that should be placed within the responsible class rather than be loosely coupled through some viewmodel object, which is a UI thing...?
I don't think this loose coupling pushes business logic out to the UI at all. The ItemCreator is presenting a collection and pretty much says to the UI, here's a collection, do what you want with it, UI can display it upside-down for all the ItemCreator cares. What it does care about is if the UI breaks any of business rules which are still contained within the Collection, It will let UI know of the broken rules. The Business Rules are still contained within ItemCreator. This loose coupling also has some other advantages such as being able to use it on multiple UIs or Test scenarios.
I was talking about NOT exposing the collection through the ItemCreator, but just keep it as a property on the ViewModel. That is what I meant with loose coupling, and I thought you were promoting that idea.
At the moment I still see the ItemCreator being saved at the end of the process, persisting a new inventory item. That is the reason I did not want to have the lookup collection as a child inside ItemCreator.
But the more I think about it, the ItemCreator class could end up being a UOW object. Then the matching items collection would becomes a child property of the UOW object.
In my case I cannot rely on business rules involving the collection, because it is not possible to determine what an empty/big collection really means. Are there really no matching items? Or did the user fail in entering the right search criteria... But I can add a boolean property NoMatchesFound to the ItemCreator class, and add a corresponding business rule that, for validity, expects that property to be true. Then the collection is only a UI helper, that enables the user to make a decision and manually set the NoMatchesFound property on the ItemCreator.
Any other ideas?
Copyright (c) Marimer LLC