For information and reference only – not to be submitted as your own work.

This extract shows how a strong submission for the BBIS 5101 Assignment 3 Campus Facilities Issue Register brief can be organised: a short design section, the key C# code, a test table and a debugging account. It is an abridged model, not a full solution. Our planning advice for this type of task is in the companion article, how to plan a C# Windows Forms CRUD assignment. Citations follow APA 7th edition.

Planning table

Task 1.1: Business purpose and functional requirements

A tertiary provider currently records faults such as failed lighting or damaged furniture on paper forms and spreadsheets. Entries are duplicated, status changes are lost and staff cannot easily see which problems are still open. The Campus Facilities Issue Register replaces these records with a single Windows Forms application backed by a local database. Staff can log a fault, review all faults in a grid, correct entries, remove mistaken records and filter by location, category or status. User accounts, technician workflows, notifications and cost tracking are outside the scope of this version, so the design stays small enough to build, test and explain properly.

The functional requirements are to add, view, update and delete issues, and to search or filter them. Three business rules are enforced: location and description must not be empty; priority and status must be chosen from fixed lists; and the date reported must not be in the future. Separating these rules from the form code follows the principle that business logic should be testable without the interface (Sommerville, 2016).

Task 1.2: Data design

A single table is sufficient because the brief asks for one main table. Priority and status are stored as text but constrained in code to fixed lists, which keeps the grid readable and avoids lookup tables that are not required. The database is a SQL Server Express LocalDB file, which runs without a full server installation (Microsoft, 2026b).

Task 1.3: Class design

Two cooperating classes are used besides the forms. Issue holds one record and protects its own data through properties. IssueRepository owns every database operation and is the only class that knows the connection string. The form calls the repository and displays results; it never builds SQL. Properties with validation in the setter keep invalid state out of the object (Microsoft, 2025b), and small single-purpose classes make code easier to read and change (Martin, 2008).

Task 1.4: User interface plan

Control names use a short type prefix followed by a descriptive PascalCase name, in line with .NET naming guidance (Microsoft, n.d.).

Tasks 2.1 and 2.2: Class and database implementation

The Issue class validates through a single method so that the rules are written once and reused by Add and Update.

public class Issue
{
    public int IssueId { get; set; }
    public string Location { get; set; } = "";
    public string Category { get; set; } = "";
    public string Description { get; set; } = "";
    public DateTime DateReported { get; set; } = DateTime.Today;
    public string Priority { get; set; } = "Medium";
    public string Status { get; set; } = "Open";
    public string ReportedBy { get; set; } = "";

    public static readonly string[] Priorities = { "Low", "Medium", "High" };
    public static readonly string[] Statuses = { "Open", "In Progress", "Resolved" };

    public List<string> Validate()
    {
        var errors = new List<string>();
        if (string.IsNullOrWhiteSpace(Location)) errors.Add("Location is required.");
        if (string.IsNullOrWhiteSpace(Description)) errors.Add("Description is required.");
        if (Array.IndexOf(Priorities, Priority) < 0) errors.Add("Choose a valid priority.");
        if (Array.IndexOf(Statuses, Status) < 0) errors.Add("Choose a valid status.");
        if (DateReported.Date > DateTime.Today) errors.Add("Date reported cannot be in the future.");
        return errors;
    }
}

The repository uses ADO.NET with parameterised commands. Parameters keep user text separate from the SQL statement, which prevents malformed input from altering the query (Microsoft, 2025c). The connection and command are wrapped in using blocks so resources are released even when an exception occurs (Microsoft, 2026a).

public void Add(Issue issue)
{
    const string sql = @"INSERT INTO Issues
        (Location, Category, Description, DateReported, Priority, Status, ReportedBy)
        VALUES (@loc, @cat, @desc, @date, @pri, @sta, @by)";
    using (var conn = new SqlConnection(_connectionString))
    using (var cmd = new SqlCommand(sql, conn))
    {
        cmd.Parameters.AddWithValue("@loc", issue.Location);
        cmd.Parameters.AddWithValue("@cat", issue.Category);
        cmd.Parameters.AddWithValue("@desc", issue.Description);
        cmd.Parameters.AddWithValue("@date", issue.DateReported.Date);
        cmd.Parameters.AddWithValue("@pri", issue.Priority);
        cmd.Parameters.AddWithValue("@sta", issue.Status);
        cmd.Parameters.AddWithValue("@by", issue.ReportedBy);
        conn.Open();
        cmd.ExecuteNonQuery();
    }
}

GetAll and Search fill a DataTable with a SqlDataAdapter. The form assigns that table to the grid, which is the standard binding approach for the DataGridView (Microsoft, 2025a). Annotated screenshots of each operation should accompany these excerpts in the report.

Task 2.3: Functional features and validation

The Add button handler collects the form values into an Issue, calls Validate and only then calls the repository. If the list of errors is not empty, the messages are shown together and no SQL is executed.

private void btnAdd_Click(object sender, EventArgs e)
{
    var issue = ReadForm();
    var errors = issue.Validate();
    if (errors.Count > 0)
    {
        MessageBox.Show(string.Join(Environment.NewLine, errors),
            "Please correct the following", MessageBoxButtons.OK, MessageBoxIcon.Warning);
        return;
    }
    _repository.Add(issue);
    RefreshGrid();
    ClearForm();
}

Search accepts a location keyword and optional category and status selections. The repository builds one parameterised query that treats an empty selection as “any”, so the filter logic is not duplicated in the form.

Task 2.4: Interface and usability

Drop-down lists prevent invalid priority and status values at source, and the date picker has its maximum date set to today. After every successful add, update or delete the grid is reloaded and the inputs are cleared, so the screen always matches the database. The grid is read-only with full-row selection, which prevents accidental edits and makes the selected record obvious.

Task 3.1: Test case table

Cases should cover valid, invalid and boundary input, as recommended in standard testing practice (Myers et al., 2011). Record actual results and add a screenshot for at least the validation cases.

Task 3.3: Debugging example

During testing, updating an issue changed every row in the table rather than only the selected one. Stepping through the Update method showed that the SQL statement had no WHERE clause, because the IssueId parameter had been added to the command but not used in the text. The breakpoint on the ExecuteNonQuery line and a check of the command text in the watch window made the omission clear. The fix was to add WHERE IssueId = @id to the statement and confirm that the selected row’s identifier was stored when the grid selection changed. A new test case, updating one of three rows and confirming that the other two were unchanged, was then added to the table. This example is illustrative; a submission must describe a bug that genuinely occurred in your own project.

Tasks 4.1 and 4.2: Demonstration and code explanation

A reliable demonstration follows the order the marker will check: launch the application, add a valid issue, trigger two validation messages, edit and delete a record, then run a filtered search. When explaining the code, name each class, say what it protects or controls, and point to where encapsulation, validation and the data connection appear. Practise the sequence once with a fresh database so no unexpected data appears on screen. If you need structured help with a programming brief, see our programming homework help service, or send your requirements through the assignment order form.

References

Martin, R. C. (2008). Clean code: A handbook of agile software craftsmanship. Prentice Hall.

Microsoft. (n.d.). Capitalization conventions. Microsoft Learn. https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions

Microsoft. (2025a). DataGridView control overview (Windows Forms). Microsoft Learn. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/datagridview-control-overview-windows-forms

Microsoft. (2025b). Properties (C# programming guide). Microsoft Learn. https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties

Microsoft. (2025c). SqlParameter class (System.Data.SqlClient). Microsoft Learn. https://learn.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlparameter

Microsoft. (2026a). ADO.NET overview. Microsoft Learn. https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview

Microsoft. (2026b). SQL Server Express LocalDB. Microsoft Learn. https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-express-localdb

Myers, G. J., Sandler, C., & Badgett, T. (2011). The art of software testing (3rd ed.). John Wiley & Sons.

Sommerville, I. (2016). Software engineering (10th ed., Global ed.). Pearson.