The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Prompting for info from the domain layer

One thing that's never been clear to me when separating the UI from the business / domain layer, is how should the business layer ask for data?  As a quick example, take your classic ordering application.  Some things you order need sizes, some need colors, some need to know whether you want to order the accessory pack, some need some proof that you're over 21, etc.  When the UI says, "The customer says they want an X45B31", how do you have the BL come back and say, "Well, in that case you're going to have to tell me what color they want"?

One way I've done this is with a request / response model, where the UI calls AddToOrder with a request that says "sku=X45B31", and the BL comes back with a response saying "I need a piece of data called 'color'."  The UI prompts for color and then calls AddToOrder again with a request that says "sku=X45B31;color=red".  That was okay, but it was error prone because you had to make sure there were no side effects whatsoever until you knew for sure the AddToOrder call was going to succeed, and it was inefficient because you kept looping back and forth until you'd collected all the data you need.  I know the second can be mitigated by figuring out everything you need to know all at once, but I was wondering if people had a better paradigm.
OAB Send private email
Tuesday, January 22, 2008
it is called the controller.  It is the third pillar of the model view controller frame work.  I have seen it put in two different ways  view<==model<==controller and view<==controller==>model
Tuesday, January 22, 2008
An interesting way of doing this is thinking of the client as if it were a data source that you can query. This is advocated in this article:

Presenter First: Organizing Complex GUI Applications for Test-Driven Development

The idea is to do a "call" to an object, say a ColorProvider, which prompts the user for the additional information. This class may just put up a window with the choices available or it might encapsulate an MVP/MVC triad if the request is more involved.
JSD Send private email
Wednesday, January 23, 2008
UI layer generally contains code for input validation. That is the reason to have input box, combobox etc. in the UI.

If flexibility of the UI code is desired, it can be done by processing script passed from the business layer. The script could be simple communication protocol defined by the application (for example somethign like "pattern:color" to indicate that if the order number matches the pattern, the color field is required), or JavaScript(or any script language) code.
Wednesday, January 23, 2008
Simple solutuion:
- Different SKU for each variety of a product or extension of such.
Thursday, January 24, 2008
I had been thinking of the "Provider" type architecture, but it seems like this could get out of control as more and more things need to be prompted for.  On the other hand, passing the script to the UI seems like overkill.

Seems like there should be a happy medium.
OAB Send private email
Monday, January 28, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz