Как организовать классы Java Business object

Question

Я пишу веб-сервис, и одна из операций в службе - getShortURL(String longURL). В этом методе я сначала проверяю, существует ли в базе данных longURL, если да, верните его, иначе создайте shortURL, вставьте его в базу данных и верните клиенту.

Мое замешательство заключается в том, как организовать и назвать мои занятия. Помимо класса веб-сервиса, прямо сейчас у меня есть 3 класса:

1. URLData: Он просто имеет атрибуты URL и методы получения и установки.
2. MongoDB: Он подключается к базе данных (прямо сейчас атрибуты подключения в нем жестко закодированы), вставляет в базу данных и извлекает необработанную строку из базы данных.
3. MongoDBUtil: Этот класс снова имеет метод insert(URLData), он вызывает MongoDB.insert() для вставки в базу данных. Также имеет retrieveURLData, который в свою очередь вызывает MongoDB эквивалентный метод для выполнения фактической работы.

метод веб-службы устанавливает URLData сеттеры и называет MongoDBUtil.retrieve или insert.

1. Я имею в виду, что URLData класс должен быть назван URLDataBusinessObject и вместе с сеттеров и добытчиками может иметь вставки, обновления и удаления методов.
2. MongoDBUtil может быть переименован в UrlDAO и может иметь различные методы извлечения.
3. MongoDB более kinda Выберите класс запроса, не уверен, как его проектировать и называть.

Пожалуйста посоветуйте

Answer 1

Этот вопрос может быть больше подходит для http://programmers.stackexchange.com.

Тем не менее: да, я бы изменил именование.

1) URLDataBusinessObject Нет, никогда. Вы добавляете 14 символов в имя класса без добавления какого-либо значения. URLData было просто отлично.

2) Вы должны изменить присвоение имен вашим классам DAO не специфичными для БД, если у вас явно нет архитектуры, нацеленной на несколько баз данных, а классы, специфичные для БД, выполняют задачи, специфичные для БД.

Я предполагаю, что это не так, и поэтому вы должны дать ему более общее имя. Persistence может быть в порядке, DAO также, все, что показывает предполагаемое использование, не вдаваясь в подробности, имеет право.

3) MongoDBUtil - это ваш интерфейс к слою persistence, это не полезный класс в сердце и душе. Какова цель этого класса? Если все, что вы делаете, это цепочка вызова метода на MongoDB, вы можете также сбросить его и перейти прямо к последнему.

Answer 2

1. URLData - это хорошо. Не раздувайте свое имя класса длинными неуместными словами. Если вы хотите четко указать, что это бизнес-объект, создайте пакет, например com.yourcompany.yourproject.bo, а затем разместите его класс URLData.
2. Да, UrlDAO более специфичен, чем MongoDBUtil. Вы можете создать пакет com.yourcompany.yourproject.dao для него.
3. Выглядит хорошо для меня. Однако, если вы используете какую-то структуру (например, Spring), вам не нужно создавать свой собственный класс для хранения конфигураций подключения к базе данных.

Я предлагаю вам Google для изучения учебника по этой теме, вы узнаете, как использовать эту технологию и как назвать/orginize ваши классы.

Answer 3

Для создания простых многоуровневых интерфейсов построения проектов для всех операций и интерфейсов настойчивости для всех объектов домена. Тогда код против них, а не их конкретные реализации. Таким образом, легко заменить слой устойчивости mongo для другого, функциональность организована таким образом, что другие могут легко понять это и могут также протестировать интерфейс, а не конкретные реализации. Вы бы что-то вроде:

1. URLData интерфейс
2. класса URLDataDTO (используемый в бизнес-уровне) интерфейс
3. Постоянство
4. MongoPersistence класса (используется в сохранение слоя)

Мой текущий проект делает что-то подобное, а также работает с Mongo. Интерфейс уровня persistence имеет такие методы, как «void put (URLData)». Когда он называется конструкцией Mongo, создается новая MongoURLData из переданного URLData, извлекает DBObject, а затем сохраняется. Такие методы, как «URLData get (String id)»; работать наоборот. Mongolayer запрашивает базу данных и создает новые объекты URLDataDTO из Mongo DBObjects. Затем веб-служба отвечает за сериализацию/десериализацию объектов DTO, которые отправляются или принимаются от клиентских приложений. объекты

Мои Монго домена все унаследует от чего-то это:

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); 
} 

} 

Пример Mongo реализация будет:

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; 
    } 

}