保存窗口数据的实体的正确命名约定
我正在一个项目中工作，其中有一个窗口，可以说：NameOfWindow.java。
该窗口有一些用户将输入数据的字段，例如复选框、文本字段等。
然后将有一个非持久实体，该实体将具有相同的字段并且窗口直接映射。 （建筑师设计要求）。
我如何命名该实体，以便它相应地反映其用途？
我在想，就像在 JSF 中一样，当他们有 BackingBeans 时，例如：
- NameOfWindowBackingBean.java
- NameOfWindowBean.java
或者也许：
- OtherNameWindowData.java
- NameOfWindowEntity.java
- NameOfWindowHolder.java
- NameOfWindowDataHolder.java
列表还在继续，所以任何建议都是真的赞赏！ :)
I am working in a Project in which I have a window, lets say: NameOfWindow.java.
This window has some fields that the user will input data into, like checkboxes, textfields, among others.
Then there will be a not persistent entity that will be having the same fields and the Window is directly mapped with. (Architect Design Requirement).
How can I name this Entity so it will reflect its use accordingly?
I was thiking like in JSF, when they have the BackingBeans, so for example:
- NameOfWindowBackingBean.java
- NameOfWindowBean.java
Or Perhaps:
- OtherNameWindowData.java
- NameOfWindowEntity.java
- NameOfWindowHolder.java
- NameOfWindowDataHolder.java
And the list goes on, so any recommendation would be really appreciated! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我喜欢 NameWindowData 和 NameWindowModel。因为它在MVC模式中扮演模型的角色，而NameOfWindow实际上是视图。
I like NameWindowData and NameWindowModel. Because it plays the role of model in MVC pattern while your NameOfWindow is actually the view.
在这种情况下，我可能会选择数据。由于我使用Bean进行db操作类。
您不必太担心这些小细节。最后，真正重要的是您在整个项目中使用的命名是否一致。这样，如果您保持一致，您可以在文档“介绍”中说明您的约定。 Xxxx 是“通用”类 XxxxData 是 Xxxx 类使用的类，用于存储其数据，类似的情况。
另外，在 IDE 中更改代码总是很容易，因此您不会太担心。
In this case I would probably go with Data. As I use Bean for db operating classes.
You shouldn't worry much about this tiny details. In the end what really matters is if the naming you use in consistent along the whole project. This way if you are consistent you could in a doc 'intro' state your convention. Xxxx are 'general' classes XxxxData is a class used by class Xxxx which stores its data, something along this lines.
Plus it is always so easy to change the codein IDEs that it shouldn't bother your mind much.