Re: Transfering data between objects

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 12/09/04 

Date: Thu, 09 Dec 2004 15:45:40 GMT

Responding to Kruger...

>>>Screens know bits and pieces of the business objects they
>
> represent,
>
>>>but mostly the screens and business objects are associated
>
> dynamically.
>
>>The last sentence is a problem. In a display paradigm there should
>
> be
>
>>no business semantics.
>
>
> When I say bits, I mean essentially that the screen is aware of the
> data that it is required to provide. Hitherto, no validation has
> occurred from the screen, and the only real interaction has been load
> and post - most of which was done dynamically by using field mappings.
> Unfortunately, the screen layout has been specified for me (way too
> many UI elements on one screen IMO). The exact problem is this:

Right. One of the common reasons that UI objects and business of RDB
objects tend not to line up 1:1 for complex problems.

>
> The screen is used to capture a contract. At the very top, a contract
> type must be specified, and depending on the contract type,
> beneficiaries and life insurance may be forbidden/allowed/required.
> Unfortuantely, I wasn't allowed to create a wizard-like interface, and
> all three sets of data must be visible at the same time.

The UI shouldn't do that sort of validation because it requires
understanding the semantics of things like 'beneficiary'. One solution
is to make the user's Save a two-step process: (1) send the questionable
data to the business subsystem for validation and, it responds OK, (2)
send all the data to the business subsystem to be processed.

There is an alternative, but it has some drawbacks. As soon as the user
fills in the contract type in a control, send that to the business layer
to get a list of viable beneficiaries for that contract type. Generally
that can be done long before the user has finished providing data for
the next form field. Then the UI can validate via a value-to-value
compare without understanding the semantics of the values. The drawback
here is that the user must fill in the form in a predefined order.
[Note this is basically the same thing that one would do to dynamically
populate pick lists in the UI.]

>
> The frame that allows you to add a beneficiary, must know whether a
> beneficiary may be added/edited/deleted. Typically I would place this
> validation on the benefiary list, but courtesy of the specified layout,
> the screen containing static contract info (including the type) only
> posts to its business object behind the same button that adds the
> beneficiary changes.
>
> Therefore, I need to either know what is on the screen (via somthing
> like the datapacket), commit prematurely, or allow the user to modify
> the beneficiaries and fail the validation when they click OK. The last
> option hardly seems reasonable from a usability point of view, and the
> second option has its own obvious issues.

One is not limited to one activity just because there is one button.
One can make it a two-step process for validating added data and
committing all the data, as above. So far that sounds like it will
resolve the issues here.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • Re: WGA Questions
    ... >> LOL! ... So say you change your business name, and your customer puts ... > or any other business is not necessary for product validation. ...
    (microsoft.public.windowsxp.general)
  • Re: method signature design question
    ... > to some of the other validation failures I mentioned earlier you can ... that is also why I would model the API to support the business ... > also be provided with the customer service telephone number. ... and the implementation would then have to use exceptions to signal any ...
    (comp.lang.java.programmer)
  • Re: bad practices in n-tier architecture
    ... scalability you lose in performance. ... pass a scaled down version of your business object rather than a heavy ... than the business object needs to validate it too. ... characteristics of the validation. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: n-tier input and exceptions
    ... > validation in the browser is good because it prevents postbacks. ... I was thinking that it would be to throw exceptions ... > from the business tier to the GUI tier. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Global Pension Plan (GPP)
    ... Corporate Actions Investing - Future Share Researchers ... The way government's do business are to many good beneficiaries for ... successful share researchers benefiting your business too. ... Fund Trader's Association / Pension Fund Investment Management ...
    (sci.engr.control)