How to organize Java Business object classes

Question

I am writing a web service and one of the operation in service is getShortURL(String longURL). In this method I first check whether longURL exists in database, if yes, return it otherwise create a shortURL, insert it in database and return to client.

My confusion is how to organize and name my classes. Apart from the web service class, right now I have 3 classes:

1. URLData: It just has URL attributes and getters and setters.
2. MongoDB: It connects to database(right now connection attributes are hard-coded in it), inserts in database, and retrieves raw string from database.
3. MongoDBUtil: This class has again insert(URLData) method, it calls MongoDB.insert() to insert into database. Also has retrieveURLData which in turn calls MongoDB equivalent method to do the actual job.

Web service method sets URLData setters and calls MongoDBUtil.retrieve or insert.

1. I am thinking that URLData class should be named URLDataBusinessObject and along with setters and getters it can have insert, update and delete methods.
2. MongoDBUtil can be renamed to UrlDAO and it can have different kinds of retrieve methods.
3. MongoDB is more kinda Select query class, not sure how to design and name it.

Please advise

Answer 1

To create a simple layered design build interfaces for all the persistence specific operations and interfaces for all the domain objects. Then code against those rather than their concrete implementations. That way it's easy to swap out a mongo persistence layer for a different one, functionality is organised so that others can easily understand it and can also test against interfaces rather than concrete implementations. You'd have something like:

1. URLData interface
2. URLDataDTO class (used in the business layer)
3. Persistence interface
4. MongoPersistence class (used in the persistence layer)

My current project does something similar and also works with Mongo. The persistence layer interface has methods like "void put(URLData)". When called the Mongo implementation constructs a new MongoURLData from the URLData passed in, extracts the DBObject then persists it. Methods like "URLData get(String id);" work the other way around. The Mongolayer queries the database and creates new URLDataDTO objects from Mongo DBObjects. The web service is then responsible for serialising/deserialising DTO objects that are sent to or received from client applications.

My Mongo Domain objects all inherit from something this:

public abstract class MongoDO<T extends Object> {

DBObject dbobject = null;

public MongoDO(T dto) {
    this.dbobject = new BasicDBObject();
};

public MongoDO(DBObject obj) {
    this.setDBObject(obj);
};

public abstract T toDTO() throws StorageException;

public DBObject getDBObject() {
    return dbobject;
}

public void setDBObject(DBObject obj) {
    this.dbobject = obj;
}

public ObjectId getIdObject() {
    return (ObjectId) this.getDBObject().get("_id");
}

public void setIdObject(ObjectId id) {
    this.getDBObject().put("_id", id);
}

protected String getField(String field) {
    if (dbobject.containsField(field) && dbobject.get(field) !=null) {
        return dbobject.get(field).toString();
    } else
        return null;
}

protected void setField(String field, String value) {
    dbobject.put(field, value);
}

}

An example Mongo implementation would be:

public class MongoURLData extends MongoDO<URLData> implements URLData {
    private static final String FIELD_SHORT_URL = "surl";

    public String getShortUrl() {
        return getField(FIELD_SHORT_URL);
    }

    public void setShortUrl(String shortUrl) {
        setField(FIELD_SHORT_URL, shortUrl);
    }

    public URLData toDTO(){
        URLDataDTO dto = new URLDataDTO();
        dto.setShortURL(getShortURL);
        return dto;
    }

}

Answer 2

1. URLData is fine. Don't bloat your class name with long irrelevant words. If you want to make clear that this is a business object, create a package like com.yourcompany.yourproject.bo for example, then put your URLData class in there.
2. Yes, UrlDAO is more specific than MongoDBUtil. You can create a com.yourcompany.yourproject.dao package for it.
3. Looks fine for me. However if you use some kind of framework (e.g. Spring) you don't have to create your own class to hold the database connection configurations.

I suggest you google for some tutorial on the topic, you will learn both how to use the technology and how to name/orginize your classes.

Answer 3

This question might be suited more for http://programmers.stackexchange.com.

Nevertheless: yes, I would change the naming.

1) URLDataBusinessObject No, never. You're adding 14 characters to a classname without adding any value. URLData was just fine.

2) You should change the naming of your DAO classes to be non-DB specific, unless you explicitly have an architecture aiming at multiple databases and the DB-specific classes perform DB-specific tasks.

I'm assuming this isn't the case and thus you should give it a more general name. Persistence can be just fine, DAO as well, anything that shows the intended usage without going into specifics is eligible.

3) MongoDBUtil is your interface to the persistence layer, it's not a utility class in heart and soul. What's the purpose of this class? If all you do is chain the method call to MongoDB you might as well drop it and go straight to the latter.