Naming data access components

[Chris Fulstow]

Hi,

What are people's thoughts on naming convention for data access
components?

I'm building two classes that will be used by an ObjectDataSource for
data binding:
1. Data entity (encapsulates a single record, e.g. Employee)
2. Utility class (performs employee ADO.NET database operations)

I'm fairly settled on "Employee", but can't decide what to call the
utility class?

- EmployeeDB
- EmployeeFactory
- EmployeeUtility
- EmployeeData
- Employees

Any thoughts?

Chris

[dkode]

It really doesnt matter,

I always use something like:

EmployeeDAL (Data Access Layer) or EmployeeDA (Data Access) and
sometimes I use EmployeeDBA (Employee Database Access)

just a matter of preference

[Kerry Moorman]

Chris,

I think that whatever naming convention you decide on, using it consistently
is the key.

I always name database tables with a plural name. So, for example, I would
name a table that contains employee data Employees.

Then I always name my data access classes with the name of the table they
are providing access to, along with the suffix "DA". So the data access class
for the Employees table would be EmployeesDA.

I always name a business class that works with an individual entity with the
singular version of the name of the table where the entity is stored. So
Employee is the name I would give to a business class that works with an
employee from the Employees table.

Kerry Moorman
"Chris Fulstow" wrote:

Hi,

What are people's thoughts on naming convention for data access
components?

I'm building two classes that will be used by an ObjectDataSource for
data binding:
1. Data entity (encapsulates a single record, e.g. Employee)
2. Utility class (performs employee ADO.NET database operations)

I'm fairly settled on "Employee", but can't decide what to call the
utility class?

- EmployeeDB
- EmployeeFactory
- EmployeeUtility
- EmployeeData
- Employees

Any thoughts?

Chris

[Chris Fulstow]

Thanks Kerry, I'd agree with all that. I like the "DA" suffix, I've
also seen "DAL" (data access layer) somewhere else since I originally
posted.

On a related note, if you're using stored procedures to select, insert,
update and delete your entities, do you having any naming conventions
for those?

Chris

[Kerry Moorman]

Chris,

I don't use stored procedures for create, read, update, delete (CRUD)
operations, so I have not developed a naming convention for those kinds of
stored procedures.

I have a home-grown code generator that generates a business class and
associated data access class for an entity table. My data access class
contains methods that use SQL with parameters for the CRUD operations.

Kerry Moorman
"Chris Fulstow" wrote:

Thanks Kerry, I'd agree with all that. I like the "DA" suffix, I've
also seen "DAL" (data access layer) somewhere else since I originally
posted.

On a related note, if you're using stored procedures to select, insert,
update and delete your entities, do you having any naming conventions
for those?

Chris

[Chris Fulstow]

Kerry,

Thanks for your feedback. I've been using parameterised SQL queries so
far, but anticipated using stored-procedures in future. However, I'm
not sure if there'll be much of an advantage, and it might just add
another layer of complexity to my application.

I like the idea of using an automated code-generator, I might have to
look into something similar. I'm already loving Visual Studio's
"Encapsulate Field" refactoring feature when building entity classes.

Chris

[dkode]

I personally try to use Stored Procedures whenever possible, This way
my SQL queries are not in my code, but on the database.

Up to this point I used SP's, but recently I started using O/R Mappers
for CRUD operations which seperates the BO's from the CRUD operations
(which is much better) and as a result like the other guy said, it
generates the CRUD logic for me.