Description
A WinForms application with the following as part of a form: enter image description here
When the "Add" button is clicked, a new entry is added to the ListView
, with data from the TextBox
es and NumericUpDown
above. If an entry with the same "description" and "amount" already exists, then the "quantity" is simply increased by the value given.
Code
The form implements the following interface (partial):
public interface IMainWindow
{
IEnumerable<InvoiceItem> invoiceItems { get; set; }
void addItemToNewInvoice(InvoiceItem item);
}
The view understands domain objects and converts them to and from ListViewItem
s.
There is a Presenter
which gets an instance of the MainWindow
view (implementing the above interface) injected. The presenter then calls the properties and methods of the view.
Question
Where should the logic for determining whether a new item is added to the list or the quantity of an existing item increased, be placed? The View or Presenter? I understand that in the MVP pattern, the view should be as "dumb" as possible. However, is it fine to let the View decide whether to add a completely new row or to increment the quantity in an existing one?
-
1As a completely orthogonal point, have you considered the ergonomics of this arrangement? A simple tabular interface (working like a spreadsheet) will probably be the fastest for data entry and maintenance. And rather than asking a specific question about duplication upon each entry, either do it last in one go (when triplicates or higher multiples can be condensed in one shot), or add a visual warning or highlighting to the table as you go (but don't interrupt the data entry flow by presenting a question and requiring an immediate resolution).Steve– Steve08/31/2020 10:03:54Commented Aug 31, 2020 at 10:03
-
@Steve I did put some thought into the UX aspect of it, yes. The current arrangement works for my current user.Al2110– Al211008/31/2020 10:14:06Commented Aug 31, 2020 at 10:14
1 Answer 1
Say you are going to implement a second type of view, for example, a WPF view, and you want the WPF list to work almost identical as your Winforms list. If you place the logic for "new items = new row or increased quantity" into the views, then you have to duplicate that logic in a Winforms view as well as in a WPF view. If you place it into the Presenter, however, the logic will be required only once.
This, however, may come for the price of a more complex interface: you will probably need an additional method changeItemQuantity
or updateInvoiceItem
in the interface IMainWindow
.
Ultimatively, this is a trade-off: following the DRY principle and having the described logic in only one place versus an increased interface complexity. You have to decide what is more important in your context, and if you really require this logic in a reusable place.