Блог

У меня есть некоторый опыт работы с Django и его концепцией MVC (скорее MTV …). В моем предыдущем проекте в django я всегда пытался упаковать множество функций (методов) в Model class все, которые могли бы работать с одним объектом в Model объекте. Я знаю, что в Java EE мире гораздо больше слоев, чем 3, так как же мне это сделать в Spring ? Например, где я должен разместить функцию, которая суммирует несколько свойств объекта? В любом случае, модели в spring также называются «model»?

Просто применяйте хорошие методы OO. Если какое-то поведение может быть инкапсулировано в классе модели, то обязательно поместите его в класс модели. Например, модель, имеющая свойства a salary и a bonus , может, конечно, иметь getTotalIncome метод, который возвращает сумму зарплаты и бонуса.

Конечно, он не должен пересекать свои собственные границы. Если вычисление общего дохода требует вызова службы для применения некоторого налога на основе текущего месяца и некоторой конфигурации в базе данных, это становится бизнес-логикой и связывает ваш объект модели с уровнем сервиса, чего не следует делать. Таким образом, getTotalIncome метод в этом случае больше не должен существовать.

Как правило, нет, вы не добавляете много функций в сам объект модели. А spring — это все о хорошем дизайне. Другими словами, модель должна быть просто контейнером для информации, представляющей элементы модели. Все, что делается с моделью, должно выполняться с помощью таких вещей, как DAO. Весной мои модели обычно выглядят так:

 public class Car {
    private int id;
    private Engine engine;
    private Control steeringWheel;
    ...

    // getters and setters
}
  

С помощью DAO, подобного:

 public interface CarDao {
    public void add( Car car );
    public void update( int id, Car car );
    ...
}
  

Речь идет не столько о слоях, сколько о сохранении простоты объектов данных, чтобы вы могли перемещать их по своим корпоративным системам любым удобным вам способом без неожиданностей. В самом Spring нет ничего, что действительно заботило бы, сколько методов вы помещаете в класс, но я согласен с Лукасом, что упрощение класса сущности — лучший дизайн.

Многолетний опыт много раз приводил меня к этому выводу. «Занятые» объекты сущности рано или поздно становятся проблемой.

Хорошо, у меня был бы объект модели для Player, один для Game и, возможно, один для State. У меня был бы DAO для каждого и, у меня был бы контроллер, возможно, называемый Controller, который выполнял бы все операции. Например:

 public class Player {
    private String name;
    ...
}

public class State {
    private Map<Player, Location> locations;
    private Map<Player, Health> healths;
    ...
}

public class Game {
    private Player player1;
    private Player player2;
    private State state;
    ...
}
  

Со стандартным CRUD, таким как DAO (возможно, с дополнительными вспомогательными методами), и контроллером, который реализует интерфейс, подобный этому:

 public interface Controller {
    public void move( Player player, Location location );
    ...
}
  

Java EE изменила множество шаблонов, которые были распространены в мире J2EE. Хотя Spring не является Java EE, он был разработан вокруг той же идеи — избавиться от устаревшей громоздкости J2EE. Есть хорошая книга Адама Бьена о шаблонах J2EE, которые стали анти-шаблонами — «Шаблоны реального мира Java EE. Переосмысление лучших практик«

Одна из его глав «Постоянный доменный объект» отвечает именно на ваш вопрос. Моделируйте свое приложение с помощью реальных объектов и не заботьтесь о постоянстве в начале… JPA оказывается действительно гибким в отображении объектов расширенного домена в реляционные таблицы. Чем более сложную логику вы должны реализовать, тем проще поддерживать и развивать объектно-ориентированную персистентность.