What should I name my business classes given that LINQ data classes takes all table names?

[Ronald S. Cook]

So I have a table "Employee" and wish to have a business class "Employee".
This was possible before LINQ. But now that I am generating a .dbml for the
LINQ DataContext, it "takes over" those names for its classes.

I'd hate to have to name my business classes "EmployeeClass" or some other
non-ideal convention.

Any thoughts?

Thanks,
Ron

 

[Fernando Gómez]

So I have a table "Employee" and wish to have a business class
"Employee". This was possible before LINQ. But now that I am generating
a .dbml for the LINQ DataContext, it "takes over" those names for its
classes.

I'd hate to have to name my business classes "EmployeeClass" or some
other non-ideal convention.

Any thoughts?

Thanks,
Ron

I usually like naming my data layer classes prefixed with Data, like
DataEmployee, DataCustomer, DataOrder, etc.

 

[Arne Vajhøj]

So I have a table "Employee" and wish to have a business class
"Employee". This was possible before LINQ. But now that I am generating
a .dbml for the LINQ DataContext, it "takes over" those names for its
classes.

I'd hate to have to name my business classes "EmployeeClass" or some
other non-ideal convention.

XxxxClass is not a good class name,

Only distinguishing by name space is not a good approach either.

If you write the LINQ stuff yourself then you can choose a class name
different from the table name, but let us focus on the problem
as described.

There should be some difference between the two classes and
that difference should be reflected in the name.

EmployeeRole maybe.

Arne