DTO, DAO, and DCO. What is a DCO?

Question

My search for the meaning of DCO was quite fruitless, so I decided to ask here. In my Java application, there are many classes like EmployeeDetailsDto, EmployeeDetailsDao, but recently I also came across EmployeeDetailsDco. Does anyone know what does the DCO stand for?

Answer 1

DTO = Data Transfer Object

DAO = Data Access Object

DCO = Dynamically Configurable Object?

From the article

Dynamically configurable object (DCO)

an object whose implementation can change incrementally after it is running

• consists of interface elements
• public function
• private function
• private data along with all accessor functions
• member functions support incremental changes to interface elements
• adding, removing, or altering

Answer 2

I just spoke to the guy who used to remember what this stands for. It's pretty ironic that he no longer does. Nor do any other people here in this company.

The explanation I could find was, that it's basically a DTO, but they wanted to use DCO to differentiate between DTOs used by Hibernate and DCOs used by external systems, in this case LDAP.

So I believe the meaning of DCO could really be, as Bhushan suggests, Data Carrying object or the like, and in this case it was indeed intended to be just another name for DTO. Answer accepted. Thanks for your time! I thought DCO was an accepted acronym widely used by developers but it turned out to be just this... sorry.

Edit

---

THE answer is Data Container Object, for those interested. I have caused enough stir in the company so eventually a colleague emailed the local originator of the DCO term and, if anyone still cares to find out, it stands for Data Container Object.

Answer 3

All I can say is Data Carrying Object is not what DCO means, put "Data Carrying Object" in google and it doesn't return any hits.

Thus the terms has to be wrong.

Ok tried googling "Data Objects DCO"

and got this result, which would suggest DCO means "Data Change Objects"

My guess is a DCO is an object that holds changes, a "diff", of the Object's Data.

Answer 4

Refactor the Dtos and drop the DTO suffix.

You might want to change Dao to Store or something similar.

Firstly EmployeeSetails without Dto/dco on the end obviously is a value class holding values relating to an employee. Without another term it's obvious it's not a utility - which should be called something g like EmployeeDetailsUtil/Helper etc.

Your dao should be called EmployeeSetailsStore because that describes it's function a store of EmployeeSetsils. How or where it puts them is irrelevant they are hidden away in your code. If you really wanted to you could call it HibernateEmploteeDetaileStore etc if it used Hibernate. Your interface should be called EmployeeSetailsStore. Implementors or this interface would use the interface name as a start and add impl technology to that base name.

Last but not least String is a value here of a char array but adding Dto in this case is ugly and silly.

Only really well known acronyms like Url should ever be used. In the end Store can never be confusing while all the acronyms you mentioned don't make things clearer and in this case introduced co fusion and this coated time.

If you measure the typing using what I have suggested you actually type less characters and everything is clearer. always aim for clarity rather than terseness after all we are all fast typers so what's a few extra chars. In the end we spend more time Reading, understanding etc than typing so a few extra chars in a class name isn't going to reduce productivity at all ...

Don't skimp...do it properly from the beginning.

Answer 5

I use DCO as a data conversion object.

For example, you have:

1. A dto.User for transferring users across the network (e.g. annotated with Jackson and mapping to a JSON interface) and:
2. A dao.User for storing users in a database (e.g. annotated with JPA and mapping to a legacy database with different fields and formats from the JSON transfer object)

You need to convert between the two.

Rather than writing that conversion logic in the DTO or DAO where they don't belong, put them in a DCO.

So you have dco.User:

package com.mycompany.myapp.dco;

// converts between data access objects (DAOs) and data transfer objects (DTOs).
public class User {
    com.mycompany.myapp.dao.User toDao(com.mycompany.myapp.dto.User) {
        // dto to dao conversion.
    }

    // could call this method fromDao if that is preferred.
    com.mycompany.myapp.dto.User toDto(com.mycompany.myapp.dao.User) {
        // dao to dto conversion.
    }
}   

Then you can easily implement and test the conversions and invoke them wherever they are needed throughout the service layer.

Another usage for such a pattern might be in a model view view-model MVVM architecture for UIs when you need to translate between the model and the view-model. In such a case the view-model is bound the view and can be changed be directly manipulated by the user in the UI, but the model is kept separate, e.g. when you want to load or save changes to disk. In such cases providing a data conversion object, or DCO as I call it, can assist in the translations back and forth between the two distinct representations of the similar thing.

Note, under this understanding, the DCO is really just a set of functions rather than a stateful object. So you could just call it a DataConvertor or you you could put all of the conversion functions in a single factory class for your whole domain layer of all objects which need conversion if you preferred.

This is just something I sometimes do, and not necessarily a standard. Some other person may use DCO to stand for something else.

Answer 6

I have never heard of DCO but is it Data Carrying Object just another name for DTO?

Answer 7

This might be Command Object.