问题描述
请考虑以下示例：
Web应用程序为每个登录用户创建一个用户对象。此对象具有 firstName ， lastName 的简单 String 属性。
A web application creates a user object for every logged in user. This object has simple String properties for firstName, lastName ...
每个用户也可以有一个 car 。考虑到获取用户 car 是非常昂贵的，所以我们不想在用户登录时将用户设置为汽车，而是在用例需要时开车。
Each user can have a car too. Consider that fetching the user car is very expensive, so we prefer not to set the users car when user logs in. Instead we want to get car when a use case needs it.
为了实现这一点，我们创建了一个用户pojo：
To implement this we have created a User pojo as:
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() );
每个需要用户车的用例都可以轻松获得：
And every use case which needs the user car can get it easily:
newUser.getCar()
然而，我一直在争辩说，以这种方式，我的User对象不再是一个简单的pojo，而且这不是一个好办法。
However, I have been argued that in this way my User object is not a simple pojo any more and this is not a good approach.
如何以更好的方式实现这一要求。
How can I achieve this requirement in better way.
推荐答案
对于你的问题，我想先回想一下历史。
To anwer your question I would first like to go back a bit in history.
Pojo是一个简单的老Java对象，意味着你只使用标准的java。该术语是在J2EE有炒作的时候创建的。此时，开发人员将业务逻辑编码到企业bean中，并且此EJB需要大量的基础设施代码。这个事实将商业逻辑与实现技术相结合。所以Rebecca Parsons，Josh MacKenzie和Martin Fowler得出的结论是，如果你只是使用标准的java，那么业务逻辑将会更加可重用，更容易测试。因此，他们创建了一个术语，因为开发人员喜欢花哨的名字。
Pojo is a plain old java object and means that you only use "standard" java. The term was created at a time when J2EE had it's hype. At this time developers coded business logic in enterprise beans and this EJBs needed a lot of infrastructure code. This fact coupled buisness logic to an implementation technology. So Rebecca Parsons, Josh MacKenzie and Martin Fowler came to the conclusion that business logic would be more reuseable and easier to test if you just use standard java. Thus they created the term pojo, because developers like fancy names.
您的 用户 类只依赖于标准的java，因此它是一个pojo 。
有些开发人员认为，pojo不应该包含任何逻辑。这些开发者喜欢贫血模型。其他人说，富有的模式是更好的做法。我属于那些喜欢贫穷模型的开发人员。
Some developers argue that a pojo should not contain any logic. These developer prefer anemic models. Others say that a rich model is the better approach. I belong to the developers who prefer a rich model over an anemic model.
如果你想删除 CarServices 依赖于 User 类，您可以实现一个 Car 延迟加载代理，就像hibernate或一个jpa实现。
If you want to remove the CarServices dependency from the User class you can implement a Car lazy loading proxy just like hibernate or a jpa implementation does.
至少这里有一些对豆，pojos，贫血和富域的模型的想法。
At least here are some of my thoughts to beans, pojos, anemic and rich domain models.
- The difference between pojos and java beans
- Anemic vs. Rich Domain Models
希望当您与其他开发者讨论时，它可以帮助您。
Hopefully it helps you when you discuss wih other developers.
这篇关于设计一个具有延迟加载属性的Java POJO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！