Сомнения в архитектуре проекта Spring MVC - DAO, Модели, Сервисы - PullRequest
Новая
       23

Сомнения в архитектуре проекта Spring MVC - DAO, Модели, Сервисы

0 голосов
/ 16 ноября 2018

Я изо всех сил пытаюсь найти лучшие практики для архитектуры моего проекта Spring. В настоящее время наша компания имеет большую схему базы данных, которая используется во многих проектах, и мы используем только подмножество, точнее 10 таблиц. Наше приложение использует слой DAO для доступа к этим таблицам.

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

Наши DAO слои автоматически связывают jdbcTemplate (мы не используем ORM). Теперь возникает первая проблема: многие из наших уровней DAO имеют обычные операции CRUD + множество «методов обновления», и DAO становится раздутым. Для каждого нового варианта использования нам нужно добавить новый метод для интерфейса и реализации. Визуальная демонстрация: 

public class Employee {
    private Integer id;
    private Integer first;
    private Integer second;
    private Integer third;
    private Integer foreignId;
    private Integer sts;
    private Integer activityMark;
    private Timestamp tstam;
}


public class EmployeeDao {
    Employee get(Integer id);
    Collection<Employee> getAll();
    void remove(Integer id);
    void updateFirst(Integer id);
    void updateSecond(Integer id);
    void updateThird(Integer id);
    void updateSts(Integer id);
    ....
}

Другой вариант - использование одного метода обновления, но для этого требуется другой ненужный запрос (выбор всего) из базы данных.

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

public class ModelOne {
    private ModelTwo m2;
    private ModelThree m3;
}

и иногда только с атрибутами внешнего ключа или необходимости.

и у них также есть соответствующие методы в DAO. Иногда они имеют свой собственный интерфейс и реализацию DAO, а иногда они все вместе с основной моделью DAO. Мы пытаемся сбалансировать между DAO на основе таблиц и моделей.

Наконец, у нас мало сервисов, которые автоматически связывают DAO, и это нарушает принцип единой ответственности.

Я прочитал много статей, много обсуждений, но мне кажется, что ни одна из них не дала хорошего решения моих проблем. Извините за длинную историю, но я буду благодарен за любой совет.

1 Ответ

0 голосов
/ 16 ноября 2018

Почему бы вам не использовать только один метод обновления для объекта сотрудника, который получает объект Employee в качестве параметра? Вы можете просто обновить нужное поле в экземпляре Employee. Hibernate позаботится об обновлении того, что вы хотите.

...