请考虑下面的例子：
Web 应用程序为每个登录用户创建一个用户对象。这个对象有简单的String属性为firstName, lastName ...
每个用户都可以拥有一个car也。考虑获取用户car非常昂贵，因此我们不希望在用户登录时设置用户的汽车。相反，我们希望在用例需要时获取汽车。
为了实现这一点，我们创建了一个用户 pojo：
public class User() {
private String FirstName;
private String LastName;
private Car car;
//Here we have the service object, this could be injected with spring or JEE
private CarServices carServices;
public Car getCar() {
//If the car is not fetched yet, go on and get it from your service
if (car == null) {
car = carServices.getCarFromDB(...)
}
return car;
}
}
登录后的初始用户：
User newUser = new User();
newUser.setFirstName("foo");
newUser.setLastName("bar");
//We just let user have service, so he can use this service latter
newUser.setCarServices( new CarServices() );
每个需要用户汽车的用例都可以轻松获得：
newUser.getCar()
然而，有人认为，通过这种方式，我的 User 对象不再是一个简单的 pojo，这不是一个好方法。
我怎样才能更好地实现这个要求。
有人认为，通过这种方式，我的 User 对象不是一个简单的 pojo
为了回答你的问题，我首先想回顾一下历史。
波乔是一个普通的旧java对象并意味着您只使用“标准”java。这个术语是在 J2EE 大肆宣传的时候创建的。此时，开发人员在企业 Bean 中编写业务逻辑，而 EJB 需要大量基础设施代码。这一事实将业务逻辑与实现技术结合起来。因此，Rebecca Parsons、Josh MacKenzie 和 Martin Fowler 得出的结论是，如果只使用标准 java，业务逻辑将更具可重用性并且更易于测试。因此他们创造了这个词pojo，因为开发人员喜欢花哨的名字。
Your User类仅依赖于标准 java，因此这是一个pojo.
一些开发人员认为 pojo 不应该包含任何逻辑。这些开发人员更喜欢贫血模型。其他人则认为丰富的模型是更好的方法。我属于那些更喜欢丰富模型而不是贫乏模型的开发人员。
如果您想删除CarServices依赖于User类你可以实现一个Car延迟加载代理就像 hibernate 或 jpa 实现一样。
至少这里是我对 beans、pojos、贫血和丰富领域模型的一些想法。
- pojos和java beans的区别
- 贫乏领域模型与丰富领域模型
希望它在您与其他开发人员讨论时对您有所帮助。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
