One of the things you'll notice when using the LINQ to SQL
designer is that it automatically "pluralizes" the various table
and column names when it creates entity classes based on your database
schema. For example: the "Products" table in our example
above resulted in a "Product" class, and the
"Categories" table resulted in a "Category" class.
This class naming helps make your models consistent with the .NET naming conventions,
and I usually find having the designer fix these up for me really convenient
(especially when adding lots of tables to your model).
If you don't like the name of a class or property that the
designer generates, though, you can always override it and change it to any
name you want. You can do this either by editing the entity/property
name in-line within the designer or by modifying it via the property grid:
Figure 6
The ability to have entity/property/association names be
different from your database schema ends up being very useful in a number
of cases. In particular:
1) When your backend database table/column schema
names change. Because your entity models can have different names
from the backend schema, you can decide to just update your mapping rules and
not update your application or query code to use the new table/column
name.
2) When you have database schema names that aren't very
"clean". For example, rather than use "au_lname" and
"au_fname" for the property names on an entity class, you can
just name them to "LastName" and "FirstName" on your entity
class and develop against that instead (without having to rename the column
names in the database).
