Winforms Update form label from a class library

[User 4333461]

Hi, I was wondering if anyone could help me. I have a solution which contains three projects. One for data access , one for business logic and the other contains for the winforms them self and is set as the startup project. In my winform I create instance of a method which is in BLL project. This creates the controls dynamically based on some fields in the database. I also attach the button click evens in this class. On the button click event I need to update the text in a label. How would I go about this? If I move the class file in to the starup project I can update it by passing the form name and updating a property. But I would like to keep the class file in the BLL project. Can anyone help? Thanks

[BobJanova]

Creating controls is not business logic. This should be done by the UI layer. What the business layer should return is some object (probably a IList<FieldDefinition> or similar where FieldDefinition includes the metadata about the field that you're going to need in the view) that defines the database fields that you want controls made for. You have done the right thing by separating the three parts, try not to smear things across those lines if you can avoid it!

[User 4333461]

Thanks, so should I still keep this in its own class file and move it in to the main project. The other thing i do also which I imagine is bad practice is bind or set the value of the text box at the same time.? Thanks

[BobJanova]

That really depends on details of what the class is, whether it does anything useful and how important it is, so I can't really answer :p. Sending the value that should be put in a 'control' from the business logic (as part of a FieldDefinition type data class) is fine, as long as what you're specifying is the underlying logical value. For example you shouldn't format up a number as a string, or specify font formatting information, because that's view specific. A good test is: if you can imagine creating a non-graphical client for the method and the information it returns, it's fine to put it in there. You always need some interface code between layers and that's how you should think of this part.

[RexGrammer]

You can pass a reference to that label to a method in the class library:

public void SetText(ref Label myLabel, string text)
{
myLabel.Text = text;
}

[Luc Pattyn]

and you don't need the ref keyword to do that, better not use it here in fact. A cleaner way is by passing a delegate, so it is the control's owner who updates the control when informed about a data change. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[DaveyM69]

I agree with Luc - this is not a good method. The class library should not have or need any knowlege of any UI control. The normal way would be to get the text from the BusinessLayer vie a getter or string GetXXX() method and deal with updating the text in the UI layer. Luc's suggestion of passing a delegate is an alternative aproach which is also valid and allows the calling of the update code from the BusinessLayer without it needing information about the control - the actual update is still done in the UI layer. Delegates often confuse people but they're pretty simple so here is an example. I prefer other options but here is how it is done:

// CommonObjects class library

namespace CommonObjects
{
public delegate void UpdateText(string text);
}

// BusinessLayer class library, references CommonObjects

using CommonObjects;

namespace BusinessLayer
{
public class Strings
{
public static void RequestUpdateText(UpdateText updateText)
{
updateText.Invoke("New Text");
}
}
}

// Presentation layer - a winforms app here with a TextBox (textBox) on the main form (FormMain instance),
// references CommonObjects

using System.Windows.Forms;
using CommonObjects;

public partial class FormMain : Form
{
public FormMain()
{
InitializeComponent();
RequestUpdateFromClassLibrary();
}

private void RequestUpdateFromClassLibrary()
{
    BusinessLayer.Strings.RequestUpdateText(new UpdateText(UpdateTextBox));
}
private void UpdateTextBox(string text)
{
    textBox.Text = text;
}

}

Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

[BillWoodruff]

There are many ways to establish "dynamic connections" (access, ability to invoke method in, ability to set and get values) between different classes/objects. Injection, passing of references to instances of objects, Interfaces, inheritance, exposure of select values by use of Public Properties, etc. Many of the responses here (all technically sound) assume, I think, that the UI here is a fixed design: I'm going to play "devil's advocate" and raise the question... since you told us in the OP that the UI definition is created by a method in the "Business Layer" reading from the DataBase: "This creates the controls dynamically based on some fields in the database"." Is it possible that the UI is, itself, not a fixed design, and that it may be different with each Application "run" ... because the DataBase fields that determine UI controls are being changed, or vary depending on other processes changing the DataBase. If this (unlikely ?) hypothetical is false, why are you defining the UI in the DataBase ? best, Bill p.s. minor point: it would be a very strange scenario in which "create instance of a method" makes sense: I am pretty sure you mean that you access/invoke the method in the BL which then reads the DataBase and then one way, or another, creates the UI.

"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle