My Controller code:

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
ObjectReader objectReader = objectMapper.reader(User.class);
response.setData(userControllerDao.updateUserDao(user, id));

My Dao code:

public List<User> updateUserDao(String userName) {
 if(! userName.equalsIgnoreCase("")){
        String split[] = userName.split(",");
        for(String s: split){

I am little bit confused here in coding guidlines. As per MVC architecture I should have write business logic in controller. What about this splitting / null checking query in Dao? They should have move to Controller side?

If yes, then I still need to pass a List / String in Dao and split it again here. Does it make any sense to move them to Controller side?

1 Answer 1


DAO code goes into the Model, not the controller. DAO code is actually farther away from the controller than the business logic, and that logic doesn't go into the controller either.

Write a layer that contains methods that convert CRUD operations (Create, Read, Update, Delete) into DAO operations. Call the newly-created CRUD methods from your controller instead of the DAO code.

If you need something that maps closer to business operations, write another layer that contains methods that encompass actual business operations (such as TransferMoney, ReconcileInvoice or BuildWidget), and call your CRUD methods from this layer.

When you are done, it should look something like this:

Database <--> DAO Code <--> CRUD methods <--> Business Logic <--> Controller <--> View 
|---------------------- MODEL -----------------------------|

Everything to the left of the controller is the Model. The only thing the controller does is decide which business domain methods to call.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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