Question

我对Django及其MVC（MTV相当......）概念有一些经验。在我之前在django的项目中，我总是尝试将很多函数（方法）打包到Model class - 所有这些函数都适用于Model对象中的单个实体。我知道在Java EE世界中，层数多于3层，所以我应该如何在Spring中完成？例如，我应该在哪里放置总结实体的少数属性的函数？无论如何，春天的模特也被称为“模特”吗？

Answer 1

只需应用优秀的OO实践。如果某些行为可以封装在Model类中，那么肯定将它放在Model类中。例如，具有salary和bonus属性的模型当然可以使用getTotalIncome方法返回工资和奖金的总和。

当然，它不应该跨越自己的boudaries。如果总收入的计算需要服务的调用来根据当前月份和数据库中的某些配置来应用某些税，这将成为业务逻辑并将您的模型对象与服务层耦合，这是不应该做的。因此，此案例中的getTotalIncome方法不应再存在。

Answer 2

通常，不，您不在模型对象本身中添加许多函数。春天就是好的设计。换句话说，模型应该只是表示模型元素的信息的容器。模型所做的一切都应该通过像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 );
    ...
}

Answer 3

更少关于图层和更多关于保持数据对象简单的内容，以便您可以无论何种方式在企业系统中移动它们而不会出现意外情况。 Spring本身并没有真正关心你在一个类中放置了多少方法，但我同意Lucas的观点，即保持实体类的简单性是更好的设计。

长期的经验使我多次回到这个结论。 “忙碌的”实体对象迟早会成为一种痛苦。

Answer 4

好的，我会有一个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;
    ...
}

使用像DAO这样的标准CRUD（可能还有其他辅助方法），以及实现类似这样的接口的控制器：

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

Answer 5

Java EE改变了许多J2EE世界中常见的模式。虽然Spring不是Java EE，但它是围绕同样的想法设计的 - 以摆脱遗留的J2EE繁琐。 Adam Bien有一本关于J2EE模式的好书，它已成为反模式 - “Real World Java EE Patterns. Rethinking Best Practices”

其中一章“持久域对象”完全回答了您的问题。使用真实对象为应用程序建模并且不关心开头的持久性... JPA在将富域对象映射到关系表时非常灵活。您必须实现更复杂的逻辑，可以维护和开发更容易的面向对象的持久性。

Spring - 除了getX和setX之外，实体类应该包含方法吗？

5 个答案: