Feld vs Eigenschaft C# (Wie es für Entwickler funktioniert)

What Is a Field?

A field is a variable that is declared directly in a class or struct. Fields are typically used to store data directly, making them simple but risky when it comes to encapsulation and control.

public class DocumentSettings
{
    public string headerText; // Field
}

public class DocumentSettings
{
    public string headerText; // Field
}

Public Class DocumentSettings
	Public headerText As String ' Field
End Class

Fields are fast and lightweight but lack protections like access modifiers, setter methods, or validation logic. That’s why they should be used cautiously—especially when the value is accessed directly by external code.

What Is a Property?

A property in C# acts as a controlled interface to a field. It provides a flexible way to retrieve or assign a property value while allowing additional logic inside its get or set accessors.

public class DocumentSettings
{
    public string HeaderText { get; set; } // Property
}

public class DocumentSettings
{
    public string HeaderText { get; set; } // Property
}

Public Class DocumentSettings
	Public Property HeaderText() As String ' -  Property
End Class

Properties are ideal for public data access because they offer encapsulation and can easily integrate with frameworks that use reflection, like IronPDF.

Key Differences Between Fields and Properties

Feature

Field

Property

Encapsulation

No

Yes

Backing logic

Not possible

Supported via get/set

Reflection-friendly

Not reliably

Yes

Data binding

Not ideal

Preferred

In short: use properties for public-facing data, especially when you're working with tools like IronPDF that rely on reflection or serialization.

Example: PDF Export Configuration

// Field: Might be ignored
public class PdfExportOptions
{
    public string footerHtml; // fields store data directly, but not safely
}
// Property: Recognized and controlled
public class PdfExportOptions
{
    public string FooterHtml { get; set; } // easy to modify, validate, or hide
}

// Field: Might be ignored
public class PdfExportOptions
{
    public string footerHtml; // fields store data directly, but not safely
}
// Property: Recognized and controlled
public class PdfExportOptions
{
    public string FooterHtml { get; set; } // easy to modify, validate, or hide
}

' Field: Might be ignored
Public Class PdfExportOptions
'INSTANT VB NOTE: The field footerHtml was renamed since Visual Basic does not allow fields to have the same name as other class members:
	Public footerHtml_Conflict As String ' fields store data directly, but not safely
End Class
' Property: Recognized and controlled
Public Class PdfExportOptions
	Public Property FooterHtml() As String ' -  easy to modify, validate, or hide
End Class

Serialization & Data Binding in IronPDF

IronPDF features like HTML templating, form filling, or metadata insertion depend on properties because they’re accessible via reflection. If you’re passing data to templates or exporting forms:

• Fields may be skipped entirely.
• Properties ensure the data is correctly retrieved and rendered in the final file.

This is especially crucial when working with complex models or user-generated data.

Use Properties for Public API Interaction

If your model is consumed by IronPDF (or any external library), use public properties with appropriate access modifiers to ensure safe, maintainable access.

public class InvoiceData
{
    public string CustomerName { get; set; }
    public DateTime InvoiceDate { get; set; }
}

public class InvoiceData
{
    public string CustomerName { get; set; }
    public DateTime InvoiceDate { get; set; }
}

Public Class InvoiceData
	Public Property CustomerName() As String
	Public Property InvoiceDate() As DateTime
End Class

This ensures that IronPDF (and other .NET libraries) can access the values via reflection and serialization.

Keep Fields Private and Internal

Use fields for internal logic where you don’t want external components or libraries to access the data.

public class InvoiceData
{
    private string internalNote; // Not meant for IronPDF
}

public class InvoiceData
{
    private string internalNote; // Not meant for IronPDF
}

Public Class InvoiceData
	Private internalNote As String ' Not meant for IronPDF
End Class

This is a good practice for keeping your logic clean, secure, and predictable.

Fields: Less Secure, Less Controlled

Fields expose data directly, without any logic or guardrails. When you declare a public field, you open that value up for direct modification from anywhere in your application—or even by external libraries.

// Field – no protection
public class Person
{
    public string name;
}

// Field – no protection
public class Person
{
    public string name;
}

' Field – no protection
Public Class Person
	Public name As String
End Class

With this setup:

• Anyone can read or write the author value without restrictions.
• You can’t intercept changes to apply validation, logging, or sanitization.
• Libraries like IronPDF could consume or override this data in unexpected ways if misused.

This lack of control becomes a potential security risk, especially when handling user input, generating dynamic documents, or exposing internal objects across boundaries (e.g., via APIs, serialization, or Razor templates).

Properties: Safer, More Flexible

Properties allow you to control access to your data using get and set accessors. You can enforce rules, validate inputs, and restrict write-access—making them far more secure.

// Property – safer use of our Person class
public class Person
{
    private string _name;
    public string Name
    {
        get => _name;
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Name is required");
            _name = value.Trim();
        }
    }
}

// Property – safer use of our Person class
public class Person
{
    private string _name;
    public string Name
    {
        get => _name;
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Name is required");
            _name = value.Trim();
        }
    }
}

' Property – safer use of our Person class
Public Class Person
	Private _name As String
	Public Property Name() As String
		Get
			Return _name
		End Get
		Set(ByVal value As String)
			If String.IsNullOrWhiteSpace(value) Then
				Throw New ArgumentException("Name is required")
			End If
			_name = value.Trim()
		End Set
	End Property
End Class

This approach:

• Prevents bad data from being stored.
• Gives you hooks to log access or enforce business rules.
• Protects the internal state of your application.
• Ensures any third-party library (like IronPDF) can safely and predictably consume your data.

In sensitive scenarios—such as generating official PDFs with user metadata, invoices, or audit logs—using properties gives you full control over what goes in and out of your objects.

Why This Matters with IronPDF

IronPDF doesn’t inherently “violate” your data integrity, but it does rely on reflection in many areas. If you're passing data models into Razor templates, metadata fields, or export configurations:

• You want to ensure only sanitized, validated values are exposed.
• You want control over how data is written and read.

Using properties allows you to control this flow, while public fields leave your application more exposed to unintended behavior.

What This Code Does

• Creates a PdfMetadata class with a sanitized property.
• Uses ChromePdfRenderer to render a basic HTML template.
• Injects the sanitized author data into both the HTML content and the PDF metadata.
• Saves the final output to SecureOutput.pdf.