3

I am building a small Java web application using Spring MVC, Hibernate and I am confused about the DAO classes methods naming.

For example I have an InvoiceDAO.java class which I thought should contain the following methods:

Save(Invoice newInvoice);
Void(Invoice oldInvoice);
getInvoiceByID(Long invoideID);

but my boss says that best practices says that I should have methods names in DAO classes as follows:

add(Invoice newInvoice);
update(Invoice oldInvoice);

which makes no sense for me as I am not sure how I can name voiding an invoice as Update?!!

So can someone please guide me in this and tell me if I am wrong on my methods naming? In other words is it correct that I should only use add, update for naming or can I use any naming and still be considered as best practices.

thanks

MChan
  • 6,842
  • 27
  • 83
  • 132
  • 1
    Update = change data of an existing entity. even with no data. And please obey the Java naming conventions: http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367 – Marco Forberg Jul 10 '13 at 21:04
  • See this article about naming conventions: http://java.about.com/od/javasyntax/a/nameconventions.htm – Branislav Lazic Jul 10 '13 at 21:05
  • 5
    A DAO shouldn't contain business logic. It should just insert, update, delete, read, and query the database. Voiding an invoice (whatever that might mean) isn't such an operation. – JB Nizet Jul 10 '13 at 21:06
  • You can use spring data, you don't need to write your own DAOs. – Nathan Hughes Jul 10 '13 at 21:07
  • 1
    What JB Nizet mentioned is often called CRUD: create, read, update, delete – Marco Forberg Jul 10 '13 at 21:08

4 Answers4

9

Voiding an invoice is a business operation. I would say such logic lives in your service layer. You make updates to the invoice to mark it as void, and then pass it to the data layer to save.

The data layer should contain pure CRUD type methods, that is add/save/find.

Using many modern data frameworks, you don't even need to write the data layer ... e.g. see http://blog.springsource.org/2011/02/10/getting-started-with-spring-data-jpa/

dan carter
  • 4,158
  • 1
  • 33
  • 34
  • +1 re Spring Data JPA. It's hugely helpful, and you can sidestep the whole debate about best names for the CRUD operations. –  Jul 10 '13 at 21:40
  • @dan So what you saying is that in DAO layer I shall only maintain CRUD methods (Save, Update, Delete, Search), while in Service layer I shall add all business logic for example (voiding an invoice, adding new items to inventory...etc) then call DAO methods from within Service layer to complete business logic tasks...correct? – MChan Jul 10 '13 at 23:57
  • 1
    @MChan exactly. Separation of Concerns. Keeping all the database interfacing code out of the business logic makes the business logic easier to follow and maintain. – dan carter Jul 11 '13 at 00:23
8

I've found this refeernce some time ago about DAO naming ...

Names according to function

getData* Data Parsing Methods used internally in DAO, do not use this namespace for data accessing.

get* (e.g. getUsersByID) SELECT queries – It is encouraged that you try to use the noun in Singular or Plural according to single or multi-row return.

set* (e.g. setActive) UPDATE Queries

add* (e.g. addUser) INSERT Queries – It is encouraged that you try to use the noun in Singular or Plural according to single or multi-row insert.

delete* (e.g. deleteUser) DELETE queries

is* (e.g. isActive) IF check returns boolean, i.e., if ($user_dao->isUserActive($id)) or if ($post_dao->isPostInStorage($id))

count* (e.g. countUsers) Returns integer with the item count.

Reserved functions

insert – takes an object as argument, and inserts it to the table.

save – takes an object as an argument, and stores the data in it back to data backend

poke – Takes an ID as argument, “pokes” the record (sets “last seen” or whatever to now), returns update count (usually 1)

Other things to remember

As the storage Backend may or may not be a “database”, it would be encouraged not to create methods with names that imply that the backend is using a database.

Cristian Meneses
  • 4,013
  • 17
  • 32
3

First of all, in Java, at least, you name your methods with the first letter of each internal word capitalized, camel-case. You can see at the section Methods this: Java Naming Conventions

Regarding the specific naming of your methods inside the dao: I would go by creating basic crud operations that can be performed to your model classes Example:

add(Invoice invoice)
update(Invoice invoice)
// or instead 
save(Invoice invoice) // which will perform either add or update
delete(Invoice invoice) // or delete(int invoiceId)
findById(int invoiceId)
// and so forth

I would not make use of the term "void" inside the dao, since that is related to the business. Do the dao as simple as possible and after that in your service that will be using the dao, you can name your methods related to the business required (i.e. voice(Invoice invoice))

There is another possibility to create a generic dao with the basic CRUD operations and maybe you can then start naming the methods as you want:

public class InvoiceDAO inherits GenericDao<Invoice> {
    // all the above methods would be inherited
    // add specific methods to your dao
}

Again, if I were you I would move the naming of specific stuff in the service. Now it's up to you how you want to approach from what I showed. The idea is to keep the dao as simple as possible.

You might as well go and name your void method (since you can do name it void, since in Java is a keyword -- thanks @Marco Forberg for noticing that) either delete (Void - means that it is deleted.) or performVoid. Or go simple with update if you are not removing the invoice from the database after you void it. update can be applied to any changes you made for your invoice entry.

Andrei Sfat
  • 8,440
  • 5
  • 49
  • 69
0

Save and add have 2 different meanings. As do Void and update. Use the term that accurately describes what the method is doing. Im not aware of any specific best practise here.

Also, I would tend to only pass an ID into a void method if that is enough to perform the action. This is different scenario from an update where you may expect to update multiple attributes on the invoice.

Evoke
  • 11
  • 2