Ronald S. Cook wrote:
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