I'm thinking about a good way to implement the following scenario.
Let's assume the well-known scenario where there's an OrderEdit and LineItemEdit objects (with a LineItems collection to connect them).
What if I want a SimpleOrderEdit where :
The use case for something like that could be a quick checkout in an online store.
While I can imagine a SimpleOrderEdit object with a set properties like CustomerId, ItemNo, ShippingCharge etc. I wonder how to handle the case where someone tries to open/modify an order with multiple items using the SimpleOrderEdit class.
Since the object was really designed to deal with simple orders (only containing one item) what are the options to communicate the fact that the order contains more items and only part of the information is retrieved (exception, business rule that might prevent saving, ...)
Is there a better approach to this kind of problem ?
I'm not sure what you will gain from the SimpleOrderEdit that could not be solved using ordinary OrderEdit with another View/UI. You could always load the OrderEdit an check for one line/multiple lines and open the proper view.
Your code should not allow an order with more than one line item to be edited by SimpleOrderEdit.So imo, your program should automatically switch to a FullOrderEdit rather that presenting an error to your user if basket contains more than one item.
If you go down the path to create separate objects then I'd reccommend
1. The SimpleOrderEdit Fetch method should throw an exception if more than one LineItem was found.
2. And add AuthorizationRules on LineItemList for :
thanx for the quick reply. I initially didn't intend to create a separate object like SimpleOrderEdit.
But it seems to be a use case on its own and the main question is of course the different view/UI for this scenario. I would assume that databinding could be tricky using the regular object (OrderEdit) when the form doesn't acount for multiple line items.
The form that I had in mind would probably just have (in a simplified world) just 3 Textboxes (for customerid, itemno and shipping charge).
I'm planning on doing something very similar in a new app and the reason I'm doing it is to make the UI appear simpler in simple cases. In the old days I would have two UI's for this but it makes more sense to have the UI adapt when more than one item is added otherwise show a simple UI.
Unless you're referring to some underlying performance issue this seems to be more of a UI issue as Johnny said.
Your SimpleOrderEdit could have an OrderItem property instead of OrderItems. Probably your use of this object would be some kind of express checkout, so you end up on the "enter details" (shipping, billing, payment). This likely wouldn't be tied to any sort of cart; abandoning the "quicky checkout" would likely abandon the entire process.
Of course I assume all details of this feature have already been worked out; otherwise it seems you're inventing a use case for the sake of doing so, and YAGNI. :-)
Copyright (c) Marimer LLC