locked
Thoughts on encapsulating control visibility values into a non-UI layer (possibly BLL)... RRS feed

  • Question

  • I have been pondering about how to better relegate the logic and setting of values to indicate whether a UI control is visible or not visible.

    For example, look at the following code which is what I do not like:

    'This would be some example code in a UI code behind file:
    
    If MyBusinessObject.Condition = "Proceed" Then
    
        Me.Control1.Visible = True
    
        Me.Control2.Visible = True
    
    Else
    
        Me.Control1.Visible = False
    
        Me.Control2.Visible = False
    
    End Of
    
    

    I do not like this method, and I am looking for better ideas of at a minimum relegating the 'If Condition - Else' logic down to the BLL and setting properties at that level that indicate the controls visibility sate.  It could look as follows:

    '...again at the UI level
    
    Me.Control1.Visible = MyBusinessObject.IsControl1Visible
    
    Me.Control2.Visible = MyBusinessObject.IsControl2Visible
    
    

    At least in the example above, the UI does not know knowledge of why the controls should be visible or not visible.  But even this method seems like maybe not the best approach.  I have even thought about having the BLL raise events that the UI would handle and within here set the control's visibility, but I am not sure about this either.

    So I am looking for some thoughts on what a decent approach to setting the UI's controls visibility based on business logic including implementation.  Anyone have some ideas on this?

    All ideas are welcome, thanks!
    Monday, February 15, 2010 9:59 PM

Answers

  • Personally, Visibility is a View concern, so having this be part of the UI layer seems appropriate to me.

    The business layer shouldn't know about presentation - putting "IsControl1Visible" into the business layer seems wrong.  What happens if you decide that you should be disabling these controls instead of hiding them, for example?  That requires changing the business layer.

    That being said, Silverlight and WPF handle this case much more elegantly - instead of having this in the code, you can just bind the visibility directly to MyBusinessObject.Condition, which much more elegant.

    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by atconway Tuesday, February 16, 2010 3:40 PM
    Monday, February 15, 2010 10:03 PM
  • I agree with Reed. This should be part of the UI component and not part of the BL.

    Think about building your BL in such a way that it could be reused regardless of the UI.

    For example, say that "management" decides that the application should now have a Web piece. If your BL has *no* UI code, it would also work for any Web control in your UI.

    Hope this helps.
    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    • Marked as answer by atconway Tuesday, February 16, 2010 3:40 PM
    Monday, February 15, 2010 10:24 PM

All replies

  • Personally, Visibility is a View concern, so having this be part of the UI layer seems appropriate to me.

    The business layer shouldn't know about presentation - putting "IsControl1Visible" into the business layer seems wrong.  What happens if you decide that you should be disabling these controls instead of hiding them, for example?  That requires changing the business layer.

    That being said, Silverlight and WPF handle this case much more elegantly - instead of having this in the code, you can just bind the visibility directly to MyBusinessObject.Condition, which much more elegant.

    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by atconway Tuesday, February 16, 2010 3:40 PM
    Monday, February 15, 2010 10:03 PM
  • I agree with Reed. This should be part of the UI component and not part of the BL.

    Think about building your BL in such a way that it could be reused regardless of the UI.

    For example, say that "management" decides that the application should now have a Web piece. If your BL has *no* UI code, it would also work for any Web control in your UI.

    Hope this helps.
    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    • Marked as answer by atconway Tuesday, February 16, 2010 3:40 PM
    Monday, February 15, 2010 10:24 PM
  • Excellent replies Reed and Deborah; that is exactly what I was looking to hear.

    "For example, say that "management" decides that the application should now have a Web piece. If your BL has *no* UI code, it would also work for any Web control in your UI."

    Oddly enough this is what I was trying to accomplish with the generic 'IsControlVisible' naming convention.  Typically, each UI control type regardless of the app type (Web, Windows, Silverlight, etc) has some sort of control.Visible property.  I was thinking it might be a good idea to push the logic regardless of UI type down a layer to decide when the control should be shown.  Especially if the logic to decide if the controls are visible is more in depth.  However, I agree - you kinda shift responsibility of one aspect to a better place but break it in another aspect by having any type of 'UI' logic in the BL. And obviously I never pass any UI specefic types down a layer as that would tightly couple the UI and BL to a specefic app type (i.e. passing a System.Web.UI.Control for example).  Reed- I have worked in Silverlight and the MyBusinessObject.Condition sounds intriguing, so I will look into that more.

    I am absolutely fine with keeping the logic as I have always done and as shown in my 1st example.  I just wanted some confirmation.  Thank you for your help!
    Tuesday, February 16, 2010 3:40 PM