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

  • Thread starter Thread starter Ronald S. Cook
  • Start date Start date
R

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
 
Ronald said:
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
Click to expand...

I usually like naming my data layer classes prefixed with Data, like
DataEmployee, DataCustomer, DataOrder, etc.
 
Ronald said:
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.
Click to expand...

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
 
Back
Top