Проектный подход (управляемый доменом или управляемый сервисом) - PullRequest
Новая
       3

Проектный подход (управляемый доменом или управляемый сервисом)

4 голосов
/ 04 августа 2010

Моя постановка проблемы:

Я хочу написать управление файлами дизайна (операции добавления, копирования, удаления и т. Д.).Существует два подхода:

  1. Сервис-ориентированный подход

Запись файла VO, который содержит только атрибуты файла.Например, 


public Class File {
    private boolean hidden;
    private boolean read;
    private boolean write;

    public boolean isHidden() {
        return hidden;
    }
    public void setHidden(boolean hidden) {
        this.hidden = hidden;
    }
    public boolean isRead() {
        return read;
    }
    public void setRead(boolean read) {
        this.read = read;
    }
    public boolean isWrite() {
        return write;
    }
    public void setWrite(boolean write) {
        this.write = write;
    }
}

и отдельный сервис для операций с файлами.Например: 


public Class FileService {
        public boolean deleteFile(File file) {
            //Add delete logic.
        }
        //Same way you can add methods for Add and copy file.
}
Подход, управляемый доменом (я могу ошибаться.)

Где файл VO содержит все атрибуты плюс необходимые операции: 


public class File {
    private boolean hidden;
    private boolean read;
    private boolean write;

    public boolean isHidden() {
        return hidden;
    }
    public void setHidden(boolean hidden) {
        this.hidden = hidden;
    }
    public boolean isRead() {
        return read;
    }
    public void setRead(boolean read) {
        this.read = read;
    }
    public boolean isWrite() {
        return write;
    }
    public void setWrite(boolean write) {
        this.write = write;
    }
        public boolean deleteFile() {
            //Add delete logic.
        }
        //Same way you can add methods for Add and copy file.
}

Каковы плюсы и минусы обоих подходов?

Ответы [ 2 ]

6 голосов
/ 04 августа 2010

В объектно-ориентированном языке размещение логики в самом классе, а не в классе обслуживания, является типичным подходом (и лучше ИМО).Он следует принципу «скажи, не спрашивай», например, сообщая файлу об удалении, а не прося какую-либо службу удалить его.Одной из основных причин этого является возможность наследования.Например, если у вас есть подкласс File и вы хотите, чтобы он записал сообщение журнала до того, как он будет удален, это будет трудно сделать с классом обслуживания, поскольку вам потребуется отдельный класс обслуживания для каждого подкласса.

В терминах сервис-ориентированного подхода это обычно рассматривается на более высоком уровне (т. Е. Сервис-ориентированная архитектура).Рассмотрим систему финансовых акций, у вас может быть услуга «купить акции» и услуга «продать акции».Иметь класс обслуживания, соответствующий отдельным классам (т. Е. Сервис Stock, который знает, как покупать и продавать акции), не будет очень объектно-ориентированным.

В вашей системе также может быть уровень обслуживания, которыйпредоставляет точки интеграции с другими внешними службами (например, с базой данных), но, опять же, я не думаю, что это то, о чем вы здесь говорите.Итак, я мог бы придерживаться подхода инкапсуляции логики в самом классе File.

4 голосов
/ 04 августа 2010

Без особой информации о том, какую систему вы разрабатываете, трудно произнести.Для меня выбор зависит от границ системы.

Если вам нужно предложить API, который предоставляется в качестве службы и доступен для внешнего потребителя, воспользуйтесь решением 1, это единственный путь.Если ваша система - это скорее библиотека, чей API будет использоваться внутри других приложений, используйте модель с расширенным набором доменов, как в решении 2, это намного больше ОО.Вы не хотите раздувать свой API классами сервисов, менеджеров и утилит, для которых нет реальной причины.

Но опять же, не зная вашей конечной цели, трудно сказать.

...