POCOs与DataTable对比：为何向视图传DataTable非良策？附实例解析

Great question! Let’s dive into the differences between POCOs (Plain Old CLR Objects) and DataTables, explain why sending a DataTable to a view is a bad practice, break down a concrete example of POCOs being better, and address that common myth about nulls and data types.

Why Passing a DataTable to a View Is Poor Practice #

DataTables were designed for dynamic, ad-hoc data scenarios (like quick reporting or database schema exploration), but they’re a terrible fit for feeding data to views. Here’s why:

• No Type Safety: Every value in a DataTable is stored as an object, so you’re forced to cast values at runtime. There’s no compile-time check to catch mistakes—you’ll only find errors when the app is running, which is way too late.
• Unreadable & Unmaintainable: Views using DataTables rely on magic string column names (e.g., row["CustomerName"]). A typo here leads to a runtime error, and other developers have no way to know what data the table contains without digging into your data access code.
• No IntelliSense Support: IDEs can’t autocomplete column names or tell you what data type each value is. This slows down development and increases the chance of bugs.
• Tight Coupling: Your view becomes directly tied to the structure of your database query. If you rename a column or adjust the query output, you have to hunt down every instance of that column name in the view to fix it.

POCOs Are Superior: A Practical Example #

Let’s compare how both approaches work with a common scenario—displaying customer data in a view.

DataTable Approach #

First, the data access and view code:

// Data Access Layer
public DataTable GetCustomers()
{
    using (var conn = new SqlConnection("YourConnectionString"))
    {
        var cmd = new SqlCommand("SELECT Id, Name, Email, IsActive FROM Customers", conn);
        var adapter = new SqlDataAdapter(cmd);
        var customerTable = new DataTable();
        adapter.Fill(customerTable);
        return customerTable;
    }
}

// Razor View
@foreach (DataRow row in Model.Rows)
{
    <div class="customer-card">
        <h3>@row["Name"]</h3>
        <p>Email: @row["Email"]</p>
        <p>Status: @(bool)row["IsActive"] ? "Active" : "Inactive"</p>
        <!-- Oops! If I type row["CustName"] by mistake, no error until runtime -->
    </div>
}

Notice the fragility here—typos, missing casts, and zero clarity on what data is available.

POCO Approach #

First, define a strongly typed POCO:

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string? Email { get; set; } // Nullable for optional email
    public bool IsActive { get; set; }
}

Then, the data access (using Dapper for simplicity) and view:

// Data Access Layer
public List<Customer> GetCustomers()
{
    using (var conn = new SqlConnection("YourConnectionString"))
    {
        return conn.Query<Customer>("SELECT Id, Name, Email, IsActive FROM Customers").ToList();
    }
}

// Razor View
@foreach (var customer in Model)
{
    <div class="customer-card">
        <h3>@customer.Name</h3>
        <p>Email: @(customer.Email ?? "No email on file")</p>
        <p>Status: @(customer.IsActive ? "Active" : "Inactive")</p>
        // IntelliSense tells me exactly what properties exist—no typos possible!
    </div>
}

The advantages here are obvious:

• Compile-Time Checks: Misspell customer.Nme and the compiler throws an error immediately, not when a user loads the page.
• Clear Intent: Any developer can look at the Customer class and instantly know what data is available.
• Faster Development: IntelliSense autocompletes property names and shows data types, so you write code quicker with fewer mistakes.
• Loose Coupling: If you rename a database column (e.g., CustomerName instead of Name), you just update the query alias or ORM mapping—no need to change every reference in the view.

Addressing the "No Nulls or Data Type Worries" Myth #

The claim that "DataTables let you avoid null and data type issues" is a common misconception—here’s why it’s wrong:

• Data Type Errors Still Happen: DataTables infer types from the database, but casting incorrectly (e.g., trying to cast a DateTime to int) leads to a runtime InvalidCastException. With POCOs, your ORM handles type conversion automatically, and mismatches (like a varchar column mapped to an int property) are caught at mapping time (or even compile time with strongly typed ORMs).
• Null Handling Is More Painful: DataTables use DBNull.Value for database nulls, which is not the same as C#’s null. You have to write extra code to handle this:

  // DataTable null check
  var email = row["Email"] != DBNull.Value ? (string)row["Email"] : "No email on file";
  

  With POCOs, you use nullable value types or default values, and the ORM converts DBNull to null automatically:

  // POCO null handling is built-in
  <p>Email: @(customer.Email ?? "No email on file")</p>
  

• Type Safety Prevents Mistakes: POCOs enforce data types at compile time. If your database IsActive column is a bit, the POCO’s bool property ensures you can’t accidentally assign a string to it. With DataTables, you could cast row["IsActive"] to a string and break the view without knowing until runtime.

Final Verdict #

DataTables have their place (e.g., dynamic reporting or when you don’t know the data structure upfront), but for passing data to views, POCOs are far superior. They make your code safer, more maintainable, and easier to collaborate on—all while eliminating the supposed "advantages" of DataTables when it comes to nulls and data types.

内容的提问来源于stack exchange，提问作者papagallo