5

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:

  1. Classes that describe the data returned by a SQL query or stored procedure, or
  2. 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.

  • 2
    The second thing looks like a "query" to me. – Joachim Sauer Jun 10 '13 at 14:29
  • Yes, that should be called Query I think. – Seth M. Jun 10 '13 at 14:37
  • I should probably have noted that SqlEntity also supports stored procedures. So Query isn't exactly a fitting name. :-/ – Mike Hofer Jun 10 '13 at 15:09
  • 1
    @MikeHofer don't confuse what a class does with what features it has. If you tightly couple features and class name, then you will have to rename it every time you add a new feature. – Reactgular Jun 10 '13 at 15:18
  • @MathewFoscarini I am completely open to a better name for all of these classes! I am a huge fan of clarity. Suggest something! (And do it in the answers section, so you get credit!) – Mike Hofer Jun 10 '13 at 15:35
9

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.

  • 2
    +1: whatever you do, don't look at the Spring code for naming inspiration ... – Joachim Sauer Jun 10 '13 at 14:41
  • @JoachimSauer Java is the worse for class names. It's like find Waldo. Can you find Button in AbstractButtonInterfaceSerializableImpl. – Reactgular Jun 10 '13 at 14:46
  • Not all of Java is that bad, however. The JDK is bad, but not as bad as Spring. And Guava, for example, is pretty neat in their naming. – Joachim Sauer Jun 10 '13 at 15:16
  • Good post. This is something where BDD really comes into its own as you're forced to evaluate naming conventions in the light of real business logic. – Robbie Dee Jun 10 '13 at 15:27
  • @MathewFoscarini: Currently, both SqlEntity and DataEntity derive from Entity. Your suggestion is to rename SqlEntity to Query, and drop the -Entity suffix from both of them? I like it. Only problem is that SqlEntity (as it currently stands) can handle stored procedures as well. – Mike Hofer Jun 10 '13 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.