Question

Let’s assume, we create a stored procedure that is supposed to retrieve customer details and that will be used in some sort of dashboard view. Since there are a couple of other stored procedures relevant for the dashboard as well, one might think about visually grouping the SPs by naming them accordingly:

• DASH_GetCustomerDetails
• DASH_…

Now if you create a standard DAL with .NET 2.0, you will most certainly add a strongly typed dataset and add some table adapters. By default the TA for the SP above would be named like DASH_GetCustomerDetailsTableAdapter with the datatable being DASH_GetCustomerDetailsDataTable and so on.

Typically, you’ll have some sort of business logic above them all. It might be called something like Customer with a protected property that instantiates the table adapter and a method GetDetails maybe for finally retrieving details. Or you even make that method a property itself calling it Details, so that the presentation layer can just say something like cust.Details or whatever.

However,… i am not satisfied with all that naming stuff. Could it be necessary to be able distinguishing between Stored Procedures working in the background, so that the naming should reflect that… is there any sort of best practice?

Answer 1

I would be tempted to remove the DASH from the front of the procedures. In general procedure names should reflect what the procedure does, not who is using it.

Consider the extreme case:

• get_all_customers

vs

• get_all_customers_for_dashboard
• get_all_customers_for_invoice_background_job
• get_all_customers_for_ad_hoc_report
• …

The fact that your stored procedures are used by a background part of your dashboard application is nothing to do with the procedures themselves, and naming them as such violates encapsulation.

If you wrote another application that needed the same logical queries, would you write new procedures prefixed by APPNAME?