An entity class has two roles. The first is to provide metadata to LINQ queries; for this purpose, an entity class is not instantiated. The second is to provide storage for data read from the relational data source, as well as to track possible updates and support their submission back to the relational data source.

An entity class is any reference type definition decorated with the Table attribute. A struct (value type) cannot be used for this. The Table attribute can have a Name parameter that defines the name of the corresponding table in the database. If Name is omitted, the name of the class is used as the default:

[Table(Name="Products")]
public class Product { ... }

Inside an entity class, there can be any number and type of members. Only data members or properties decorated with the Column attribute are significant in defining the mapping between the entity class and the corresponding table in the database:

[Column] public int ProductID;

An entity class should have a unique key. This key is necessary to support unique identity (more on this later), to identify corresponding rows in database tables, and to generate SQL statements that update data. If you do not have a primary key, instances of the entity class can be created but are not modifiable. The Boolean IsPrimaryKey property of the Column attribute, set to true, states that the column belongs to the primary key of the table. If the primary key used is a composite key, all the columns that form the primary key will have IsPrimaryKey=true in their parameters:

[Column(IsPrimaryKey=true)] public int ProductID;

By default, a column is mapped using the same name of the member to which the Column attribute is applied. You can use a different name, specifying a value for the Name parameter. For example, the following Price member corresponds to the UnitPrice field in the database table:

[Column(Name="UnitPrice")] public decimal Price;

If you want to filter data access through member property accessors, you have to specify the underlying storage member with the Storage parameter. If you specify a Storage parameter, LINQ to SQL bypasses the public property accessor and interacts directly with the underlying value. Understanding this is particularly important if you want to track only the modifications made by your code and not the read/write operations made by the LINQ framework. In the following code, the ProductName property is accessed for each read/write operation made by your code; a direct read/write operation on the _ProductName data member is made when a LINQ operation is executed:

[Column(Storage="_ProductName")]
public string ProductName {
get { return this._ProductName; }
set { this.OnPropertyChanging("ProductName");
this._ProductName = value;
this.OnPropertyChanged("ProductName");
}
}

The correspondence between relational type and .NET type is made assuming a default relational type corresponding to the used .NET type. Whenever you need to define a different type, you can use the DBType parameter, specifying a valid type by using a valid SQL syntax for the relational data source. This property is used only if you want to create a database schema starting from entity class definitions:

[Column(DBType="NVARCHAR(20)")] public string QuantityPerUnit;

If a column value is auto-generated by the database (which is a service offered by the IDENTITY keyword in SQL Server), you might want to synchronize the entity class member with the generated value whenever you insert an entity instance into the database. To get this behavior, you need to set the IsDBGenerated parameter to true, and you also need to adapt the DBType accordingly-for example, by adding the IDENTITY modifier for SQL Server tables:

[Column(DBType="INT NOT NULL IDENTITY",
IsPrimaryKey=true, IsDBGenerated=true)]
public int ProductID;

Other parameters that are relevant in updating data are IsVersion and UpdateCheck. You will see a deeper explanation of IsDBGenerated, IsVersion, and UpdateCheck later in the “Data Update” section.