I am working on a personal project that works with databases, and in this project I have a set of classes that are similar, so they inherit from a common base class. The problem I am faced with is that I have this nagging feeling that the names of the classes that derive from the base class do not really reflect what they actually are.
Caveat: Please ignore the fact that this looks like a reinvention of the wheel. That’s the point of the project.
The common base class is called Entity. Its purpose is to serve as the base for:
- Classes that describe the data returned by a SQL query or stored procedure, or
- Classes that describe a SQL query or stored procedure and their parameters.
Both of these classes are created by consumers of the assembly to describe the stored procedures and queries in their database, and the data they will retrieve from it.
For example, these are designed to work against the Northwind database:
public class Employee : DataEntity
{
public int EmployeeId { get; set; }
public string LastName { get; set; }
public string FirstName { get; set; }
}
[Sql(@"SELECT [EmployeeId], [LastName], [FirstName]
FROM [Employees]
ORDER BY [LastName], [FirstName]")
public class SelectEmployee : SqlEntity
{
public int EmployeeId { get; set; }
}
As it stands, I am currently calling the first of these Data Entities, and the second SQL Entities. However, I am not entirely sure that these are fitting terms. For instance, are they actually models? Is there a better term that I am not considering?
The assembly only considers public properties that have both a getter and a setter. The developer can add anything else to it if he or she needs to. So a Data Entity can be extended to include additional functionality.
Any advice would be greatly appreciated.
EDIT
It’s worth noting that you can also model stored procedures with this stuff (again, using a Northwind database stored procedure):
[Sql()]
public class CustOrderHist
{
[Parameter("@CustomerId", SqlDbType = SqlDbType.NChar, MaxLength = 5)]
public string CustomerId { get; set; }
}
The assembly automatically binds classes to stored procedures, and properties to parameters.
7
When naming classes it’s often tempting to include words that describe usage in programming terms. These words might include abstract, entity, and/or base. So you end up creating classes like AbstractOffice or BaseOffice. The name of the class implies two meanings what it does Office and how it’s used Abstract. I don’t recommend doing this. It adds extra details in the name that it doesn’t need.
KISS (Keep It Simple Stupid)
I recently refactored a project I did a year ago to use simple names, and it became much easier to read the code. Give it a try and see if it helps. You can always rename the classes later.
public class Employee : Data
{
public int Id { get; set; }
public string LastName { get; set; }
public string FirstName { get; set; }
}
[Sql(@"SELECT [EmployeeId], [LastName], [FirstName]
FROM [Employees]
ORDER BY [LastName], [FirstName]")
public class Employees : Query
{
public int Id { get; set; }
}
When you remove programming specific terms (i.e. I removed Select, Entity and renamed Sql to Query). The classes become more readable. Now their names infer only specific information (i.e. this is about an employee). The implementation that it uses SQL or represents an entity pattern is irrelevant. That information should go into the class comments not it’s name.
In the future, you will have a bug. Which description is easier to understand, and a result easier to find in the source code.
Employee John Smith is not an active member of Employees.
or
EmployeeEntry John is not an active member of SelectEmployee
That’s just an example, but later when you’re using those classes the code becomes difficult to read. A sea of terms that aren’t relevant to what the code is doing.
9