DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Business logic and the UI

  1. #1
    sstewart Guest

    Business logic and the UI


    I am currently working on a project migrating a two tiered app to a three
    tiered app. The problem Iím facing is completely separating the business
    logic from the UI. One example I have is when I have an option group, and
    the user selects option 2, I need to enable a text box and have it required.
    If a different option is selected, the textbox is disabled and not required.
    If all the business logic is inside a COM object, how can I handle this
    without making a call to the COM object every time the user selects a different
    option?

    sstewart


  2. #2
    Willy Van den Driessche Guest

    Re: Business logic and the UI

    The way I see it, the user interface manipulates a business object. When I
    enter a form (I'm working in VB but the story stays the same, mutatis
    mutandum), I take a copy of the object being manipulated and start going. UI
    manipulations are reflected in property changes. To make the thing really
    transparent, I make my Business Objects observable. Whenever a property
    changes, an event is raised. I use a polymorphic PropertyChanged event
    (with an enum per property) but an event per property would work just as
    well. The form then observes the Business object (has a reference
    WithEvents), so that it can follow each and every property change. When a
    change of one property changes multiple other, the form will notice and take
    appropriate action.

    Now the specifics for your problem. IMHO, if you have an option that
    enables or disables another textbox, then there is something in your
    business object that wants to come out. Again, IMHO the property that
    corresponds to the textbox should be a different object contained inside
    your business object. If it is not there (nothing), the text box gets
    disabled. If it is, the textbox is enabled. So again, the options you
    change on your form correspond to an (enum) property in your business
    object. Whenever the option becomes 2 (in your case), the contained object
    is destroyed. The business object sends an event so that the UI can take
    appropriate action.

    If you don't want to make a cross-process call, you have a different
    problem. IMHO the best you can do is create a proxy object on the client as
    a placeholder for the real object on the other machine or in anothr process.
    The real problem is that the proxy should be almost as smart as the real
    object (since it must also be observable and create and destroy properties
    when others are modified).

    It's not much, but I hope it helps.
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html
    "sstewart" <sstewart@wind2.com> wrote in message
    news:3b8ebbaf$1@news.devx.com...
    >
    > I am currently working on a project migrating a two tiered app to a three
    > tiered app. The problem I'm facing is completely separating the business
    > logic from the UI. One example I have is when I have an option group, and
    > the user selects option 2, I need to enable a text box and have it

    required.
    > If a different option is selected, the textbox is disabled and not

    required.
    > If all the business logic is inside a COM object, how can I handle this
    > without making a call to the COM object every time the user selects a

    different
    > option?
    >
    > sstewart
    >




  3. #3
    David Bayley Guest

    Re: Business logic and the UI

    sstewart <sstewart@wind2.com> wrote in message
    news:3b8ebbaf$1@news.devx.com...
    >
    > I am currently working on a project migrating a two tiered app to a three
    > tiered app. The problem I'm facing is completely separating the business
    > logic from the UI. One example I have is when I have an option group, and
    > the user selects option 2, I need to enable a text box and have it

    required.
    > If a different option is selected, the textbox is disabled and not

    required.
    > If all the business logic is inside a COM object, how can I handle this
    > without making a call to the COM object every time the user selects a

    different
    > option?


    I wouldn't worry about "completely separating" the logic between the 2
    tiers, just duplicate any logic in the UI as needed.

    The business tier can be written to ensure that any update requests it
    receives (whether they be from various UI layers, or other business layers)
    are strictly validated. In your example, if the option field has a value of
    2, then the text field must contain something, or else the business layer
    will throw back an error.

    The particular UI you are working on can prevent this wasted round trip, by
    making it impossible for the end-user to enter invalid data. But when you
    have a bug in your UI code, you've got the business tier to ensure invalid
    data doesn't get through and corrupt the data tier. Likewise when you build
    an alternative UI, the business logic will be there to back you up.

    Keep the business layer as the master repository for your logic, and then
    duplicate any validation in the UI if it'll make your end-user's life
    easier. Whilst this duplication may appear heresy to the programming
    mindset, IMO it leads to a more robust and flexible architecture, and when
    the tiers are physically separated it can reduce the network traffic to
    simple GetData/PutData calls on stateless (hence scaleable) business
    objects.

    --
    David.





  4. #4
    Willy Van den Driessche Guest

    Re: Business logic and the UI



    "David Bayley" <dbayley@spamless.aebacus.com> wrote in message
    news:3b90d51e@news.devx.com...
    > sstewart <sstewart@wind2.com> wrote in message
    > news:3b8ebbaf$1@news.devx.com...
    > >
    > > I am currently working on a project migrating a two tiered app to a

    three
    > > tiered app. The problem I'm facing is completely separating the

    business
    > > logic from the UI. One example I have is when I have an option group,

    and
    > > the user selects option 2, I need to enable a text box and have it

    > required.
    > > If a different option is selected, the textbox is disabled and not

    > required.
    > > If all the business logic is inside a COM object, how can I handle this
    > > without making a call to the COM object every time the user selects a

    > different
    > > option?

    >
    > I wouldn't worry about "completely separating" the logic between the 2
    > tiers, just duplicate any logic in the UI as needed.


    I could go for duplicate logic if and only if that duplication is a simple
    matter of deployment. I mean you write a class that gets used in the
    business tier as well as in the windows layer. That class has a single
    source code and the trick you pull is one of optimization where you 'link'
    the class in two DLLs, executable or whatever. The idea behind it is : most
    of the time the business logic remains stable and if it changes we'll update
    the UI layer shortly after the business tier.

    For the rest duplicate code is very much against my own very nature. It
    won't botter you if the app is small. In that case 3 layers are hardly
    needed. For the apps for which the architecture is intended, however the
    duplication kills the apps maintenance. I can tell you from experience that
    the separation of the layers pays off when you DO change the user interface.

    >
    > The business tier can be written to ensure that any update requests it
    > receives (whether they be from various UI layers, or other business

    layers)
    > are strictly validated. In your example, if the option field has a value

    of
    > 2, then the text field must contain something, or else the business layer
    > will throw back an error.
    >
    > The particular UI you are working on can prevent this wasted round trip,

    by
    > making it impossible for the end-user to enter invalid data. But when you
    > have a bug in your UI code, you've got the business tier to ensure invalid
    > data doesn't get through and corrupt the data tier. Likewise when you

    build
    > an alternative UI, the business logic will be there to back you up.


    There is a problem with this duplicate logic. The point you have is that
    when *noise* passes the UI filter, it will get caught by the business
    filter. The real problem is that if the UI filter is too strict you create
    *silence*. Things that ought to be working are not because the UI is too
    strict. I could live with a dual filter in the case where you are rather
    too strict on enforcing certain rules than too forgiving. In that case,
    however you put this 'second opinion' pattern right at the core of your
    business objects. the business validation rules are coded by -say- two
    teams so that you get a much higher chance that errors get caught. In that
    case it's much like the password confirmation dialog : everything is checked
    twice. Be aware that the second opinion pattern is too expensive for most
    companies to implement.

    if you do want to avoid the round-trip consider the 'linking' trick
    mentioned above.

    >
    > Keep the business layer as the master repository for your logic, and then
    > duplicate any validation in the UI if it'll make your end-user's life
    > easier. Whilst this duplication may appear heresy to the programming
    > mindset, IMO it leads to a more robust and flexible architecture, and when
    > the tiers are physically separated it can reduce the network traffic to
    > simple GetData/PutData calls on stateless (hence scaleable) business
    > objects.
    >
    > --
    > David.
    >
    >
    >
    > --

    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  5. #5
    David Bayley Guest

    Re: Business logic and the UI

    Willy,

    > I could go for duplicate logic if and only if that duplication is a simple
    > matter of deployment. I mean you write a class that gets used in the
    > business tier as well as in the windows layer. [...]


    I don't understand how that would work. In this example, you have a piece
    of logic that says if option 2 is selected, then the user needs to fill in a
    related textbox before the 'Save' button can be enabled.

    In your other response, you mentioned an "observable" proxy object that
    raises PropertyChanged events. But AFAICT, the only difference that would
    make is that instead of enabling the textbox in response to the option 2
    click event, you enable it in response to the proxy object's PropertyChanged
    event. The logic is still taking place in the UI code, so you're still
    duplicating it, no?

    Not that a helper class that can be used by both UI and business layers
    isn't useful for things like calculated fields, creating strongly typed
    field properties, and passing data between the layers (although personally I
    find a simple variant array more flexible and marshals much faster). But as
    in the example given, and many others, there is no silver bullet I'm aware
    of that avoids duplicating the logic.

    > There is a problem with this duplicate logic. The point you have is that
    > when *noise* passes the UI filter, it will get caught by the business
    > filter. The real problem is that if the UI filter is too strict you

    create
    > *silence*. Things that ought to be working are not because the UI is too
    > strict. [...]


    If I understand you correctly, you're suggesting keeping the textbox enabled
    all the time and leaving it up to the business layer to invalidate entries.
    That way the business layer at least gets to *see* the data and determine
    itself whether it is invalid or not in a centralised location. Apart from
    the loss in usability, isn't this placing unnecessary extra load on the
    network and server? If the data is invalid, then silence is a *good* thing
    surely?!?

    --
    David.




  6. #6
    Willy Van den Driessche Guest

    Re: Business logic and the UI




    "David Bayley" <dbayley@spamless.aebacus.com> wrote in message
    news:3b911307@news.devx.com...
    > Willy,
    >
    > > I could go for duplicate logic if and only if that duplication is a

    simple
    > > matter of deployment. I mean you write a class that gets used in the
    > > business tier as well as in the windows layer. [...]

    >
    > I don't understand how that would work. In this example, you have a piece
    > of logic that says if option 2 is selected, then the user needs to fill in

    a
    > related textbox before the 'Save' button can be enabled.
    >
    > In your other response, you mentioned an "observable" proxy object that
    > raises PropertyChanged events. But AFAICT, the only difference that would
    > make is that instead of enabling the textbox in response to the option 2
    > click event, you enable it in response to the proxy object's

    PropertyChanged
    > event. The logic is still taking place in the UI code, so you're still
    > duplicating it, no?
    >
    > Not that a helper class that can be used by both UI and business layers
    > isn't useful for things like calculated fields, creating strongly typed
    > field properties, and passing data between the layers (although personally

    I
    > find a simple variant array more flexible and marshals much faster). But

    as
    > in the example given, and many others, there is no silver bullet I'm aware
    > of that avoids duplicating the logic.
    >


    To be quite honest, I believe in the 3 (or 5 to some) layer design. I don't
    believe in location transparency, however. Most of the work I read ignores
    this problem completely. Lothka (if I'm not mistaken) goes as far as
    splitting the Business Objects in a User Interface half and a true business
    object half. This would solve the problem of round-trips since you have an
    object that handles the user interface while the 'true' business object
    stays in the business layer.
    IMHO the whole thin client stuff is not for me. I have a Ghz PC and I don't
    want to wait for some central resources to become available for my requests
    if there is no need for them. IMHO much of the business layer (especially
    validation) belongs on the client PC. That is exactly what we do. We have
    a deployment problem but nothing taht can't be solved. Most clients don't
    mind downloading a new version, as long as it is done in an intelligent way
    (dont send that extra Mb if the client version is already up to date). If
    after that, they can work happily, then they will be pleased.
    For my work I have to use a browser-based application. It's completely
    worthless because it reduces my PC to the least common denominator and I
    have to wait hours for request to be completed. I don't mind if it runs on
    a palm-held PC. It has to run on my PC.
    This being said, we deploy the business objects on the client (In theory
    they could be installed on the server, but let's keep theory out of this).
    Requests to the server are marshalled using a versioned persistence
    mechanism (Put the objects in one large string buffer, storing the versions
    along - The description is not finished but it's at
    http://users.skynet.be/wvdd2/Visual_...rsistence.html)
    .. The server then restores the objects and processes the request.
    The reason the server is able to restore the object is that the server
    always has a version of all objects that is at least as recent as the
    version on the client PC. Later versions can always read (and write) older
    versions.
    Hence my observable proxy. It is in fact just the same class but it's a
    proxy because it possibly represents another version than the one on the
    server. There is little duplicate code since the class is the same ( In
    fact it's an observable wrapper with the same interface as the business
    class - there's little point in having an observable class at the server
    side). I do admit having some special logic in my screens every now and
    then.

    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html
    My favorite quote :
    " In theory there is no difference between theory and practice. In
    practice, however, there is."



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center