如何在ASP.NET中的UI上组织我的方法[设计问题]

Question

First of all, I know it's a little long .. But I just wanted to make a clear case here .. Thank you all for your advice in advance :)

I've been trying for 3 days to figure out a good design pattern to organize the methods I use at my UI layer in my web application .. and I couldn't get it right!

What I Have :

• 19 Tables in my database

• 19 Classes each class is corresponding to a table and has properties that corresponds to this given table's columns.

• 19x2 Pages .. the first 19 pages have the proper input controls that allows me to enter information to create a new record in the table by sending it via an object of the class's type.

• the second 19 pages are for editing the existing records in the tables

What I Need :

• The first type of pages (the first 19 pages) need some helping methods (Ex: Reset the controls, AddToTheDb)

• The second type (the other 19 pages) need some helping methods (Ex: Determine what's the id of the item to edit, Update the database)

• And finally another set of methods that's going to be common between both the two types of pages.

...I've been using interfaces to force the pages to define those methods, and user this method in the answer to give the flexibility in parameters for the specific purpose methods that are sued by the pair of my 19 pages.

PS: I'm not that good, so if you any "in the first place you should have .." or such kinda advices feel free to say what you see. I'd be glad to learn from you.

Answer 1

"In the first place you should have" created a single page for each class that does both the create and the update. Whatever fields are different between the two operations can be made different when you are populating the page. That will cut down signficantly on the amount of code you have to maintain. It will also make it easier when new things are added to the classes, because the changes will need to be made in only one place.

Doing this will also solve the problem about where to put the helping methods.

UPDATE

Creating a user interface with a lot of complex state is something that a lot of people have problems with and do badly. However, there is a simple way to do it that will give good results.

The trick is to put all of your UI-state code in one place, and be very explicit about what logic controls the behavior. Never set a Visible or Enabled property (or even a Text property) in more than one place. That way the logic is clear and can be easily changed.

Here is an example:

private void UpdateUI()
{
    bool isNewRecord = (contact.ContactId == 0);

    statusLabel.Text = isNewRecord ? "Create New Contact" : "Edit " + contact.Name;
    nameTextBox.Visible = isNewRecord;

    bool isBusiness = contactTypeBusinessRadioButton.IsChecked;

    spouseCheckBox.Visible = !isBusiness;
    bool hasSpouse = !isBusiness & spouseCheckBox.IsChecked;

    spouseNameTextBox.Visible = hasSpouse;
}

Then all of your UI event code looks like the following:

protected void spouseCheckBox_Click(object sender, EventArgs args)
{
    UpdateUI();
}

Or with some explicit state control like this:

protected void addPhoneButton_Click(object sender, EventArgs args)
{
    contact.Phones.Add(new Phone());
    UpdateUI();
}

Similarly, it is very important that all data reads/writes to the UI happen in a single place, regardless of the state:

protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
         int contactId;
         if (int.TryParse(Request.QueryString["contactid"], out contactId))
             contact = Contact.Load(contactId);
         else
             contact = new ContactId();
         DisplayContact(contact);  // Only one method to display new or existing record.
    }
}

protected void saveButton_Click(object sender, EventArgs args)
{
    ReadContactFromPage(contact); // Only one method to read the screen.
    contact.Save();
}

Clearly, for complex pieces of the UI, such as open-ended lists of things, the display and input code can be factored into many method calls, but the key thing is that all of that complexity be hidden from the higher levels that interact with the page events.

Answer 2

You could create a base page class that other will inherit from. If there is common functionality there that can be reused, that's probably a good starting point. No if you are direct editing of tables, since you have like a table per class aproach, then maybe you could use some framework or create a generic edit feature for simplier tables.

Now as an advice, don't overdo the less code is better approach. Nice clean easy to understand code is much more valuable.