Java Beans作为数据存储类设计不好吗？ [英] Are Java Beans as data storage classes bad design?
问题描述
通常，JavaPractices.com是一个好主意的好网站，但是这个让我很烦恼： JavaBeans很糟糕。
本文引用了几个原因，主要是JavaBean这个术语的意思是Java Bean是一个可以在构建器工具中直观操作的可重用软件组件。不是数据存储，违反了某些模式，而且更复杂。
现在我同意最后一个，但在我看来，列表中的JavaBeans更有意义比嵌套的地图。文章声称数据库映射框架应该调用构造函数，而不是set *方法，并且对象应该是不可变的。但是在我看来，在尝试构建对象时调用set *方法比新的MappedObject（column1，column2，又一列，这是愚蠢的）更容易阅读;
除了数据库映射之外，我还使用JavaBean样式类进行其他操作，例如对于IRC机器人，每个用户的对象都会更新各种各样的事情。我不希望每次给出新信息时都创建一个新对象，我想将它添加到现有的。
所以我的问题：使用JavaBeans数据存储是一种不好的做法，应该避免，还是完全安全？
您似乎误读了文本。
现在我同意最后一个，但在我看来，列表中的JavaBeans比嵌套的地图更有意义
该文本从未提及嵌套地图作为替代方案（yiack）
...应该调用构造函数，而不是set *方法，对象应该是不可变的
这是一个很好的做法，在处理线程时特别有用。
但是我们不能说使用setter是 baaad ，特别是当一个线程正在使用宾语。那是非常安全的。
每次给出新信息时我都不想创建新对象，我想将它添加到现有的一个。
这没关系，只要你控制对象没有问题，其他一些人可能会发现更容易创建一个新对象。
使用JavaBeans进行数据存储是一种不好的做法，应该避免，还是非常安全？
不，这不是一个坏习惯。不是完全安全。取决于情况。
可变对象（不是JavaBeans本身）的问题是使用不同的线程来访问它们。
您必须同步访问权限，以避免一个线程修改对象而另一个线程正在访问它。
不可变对象没有这个问题，因为，......它们无法改变，因此，您不必同步任何东西。
为了确保一个对象是不可变的，你必须将你的属性声明为final。
class MyBean {
private final int i;
}
如果要为 MyBean分配合理的值.i 你必须在构造函数中指定它：
public MyBean（int i）{
this.i = i;
}
由于变量是final，因此不能使用setter。你可以提供一个吸气剂。
这是完全线程安全的，最好的是，您不必同步访问，因为如果两个线程试图获得<$ c $的值c> i 他们都会看到实例化时分配的值，你不必同步任何东西。
不是不好的做法或良好做法。我们必须使用单个线程，即使在像servlet这样的多线程环境中也是如此。
如果将来你必须处理多线程应用程序，你可以考虑使用不可变的JavaBean;）
<顺便说一句，BTW，创建不可变bean的替代品，仍然提供一堆setter使用
Builders ，如： 员工e = new EmployeeBuilder（）
.setName（Oscar）
.setLastName（Reyes）
.setAge（0x1F）
.setEmployeeId（123forme）
.build（）;
这与常规bean中使用的常规setXyz非常相似，具有使用不可变数据的好处。
如果您需要更改一个值，可以使用类方法：
员工e = Employee.withName（e，奥斯卡先生）;
哪个获取现有对象，并复制所有值，并设置一个新值....
public static EmployeeWithName（Employee e，String newName）{
return new Employee（newName，e.lastName，e .age，e.employeeId）;
}
但同样，在单线程模型中使用getter / setter是完全安全的。
PS我强烈建议你买这本书：有效的Java 。你永远不会后悔，你会有信息判断更好的文章，如引用的。
Usually JavaPractices.com is a good site with good idea's, but this one troubles me: JavaBeans are bad.
The article cites several reasons, mainly that the term JavaBean means "A Java Bean is a reusable software component that can be manipulated visually in a builder tool." not Data storage, violates certain patters, and is more complex.
Now I can agree with the last one, but in my eyes JavaBeans in a list makes a lot more sense than nested Maps. The article claims that database mapping frameworks should call constructors, not set* methods, and the object should be immutable. In my mind however, calling set* methods when trying to build an object is easier to read than new MappedObject("column1", "column2", "yet another column", "this is stupid");
I also use the JavaBean style class for other things besides database mapping, eg for an IRC bot, having an object per user that gets updated with various things. I don't want to create a new object every time new information is given, I want to add it to an existing one.
So my question: Is using JavaBeans for data storage a bad practice and should be avoided, or is it perfectly safe?
It seems that you are misreading the text.
Now I can agree with the last one, but in my eye's JavaBeans in a list makes alot more sense than nested Maps
The text never mentions nested maps as an alternative ( yiack )
...should call constructors, not set* methods, and the object should be immutable
This is a good practice, specially useful when dealing with threads.
But we can't say that using setters is baaad either, specially when a single thread is using the object. That's perfectly safe.
I don't want to create a new object every time new information is given, I want to add it to an existing one.
That's fine, as long as you control the object there is no problem with this, some other may find easier to just create a new object.
Is using JavaBeans for data storage a bad practice and should be avoided, or is it perfectly safe?
No, is not a bad practice. Is not perfectly safe either. Depends on the situation.
The problem with mutable objects ( not with JavaBeans per se ) is using different threads to access them.
You have to synchronize the access to avoid one thread modify the object while other is accessing it.
Immutable objects doesn't have this problem, because, .. well they can't change, and thus, you don't have to synchronize anything.
To make sure an object is immutable you have to declare your attributes as final.
class MyBean {
private final int i;
}
If you want to assign a reasonable value to MyBean.i you have to specify it in the constructor:
public MyBean( int i ) {
this.i = i;
}
Since the variable is final, you can't use a setter. You can just provide a getter.
This is perfectly thread-safe and the best is, you don't have to synchronize the access, because if two threads try to get the value of i they both will always see the value that was assigned on instantiation, you don't have to synchronize anything.
Is not bad practice or good practice. Must of us have to work with a single thread, even in multithread environments like servlets.
If in the future you have to deal with multi thread applications, you may consider using an immutable JavaBean ;)
BTW, the alternative to create immutable beans, and still provide a bunch of setters is using Builders like:
Employee e = new EmployeeBuilder()
.setName("Oscar")
.setLastName("Reyes")
.setAge(0x1F)
.setEmployeeId("123forme")
.build();
Which looks pretty similar to the regular setXyz used in regular beans with the benefit of using immutable data.
If you need to change one value, you can use a class method:
Employee e = Employee.withName( e, "Mr. Oscar");
Which takes the existing object, and copy all the values, and set's a new one....
public static EmployeeWithName( Employee e , String newName ){
return new Employee( newName, e.lastName, e.age, e.employeeId );
}
But again, in a single thread model is perfectly safe to use getters/setters.
PS I strongly encourage you to buy this book: Effective Java. You'll never regret about it, and you'll have information to judge better articles like one cited.
这篇关于Java Beans作为数据存储类设计不好吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
