Java Web 应用程序模型 - 它是否应该包含一个保存外键选择的属性？
我有两个数据库表。 一张表存储主管负责的承诺的数据。 另一个是可用程序的查找表。 program 主键是 commitment 表中的外键（承诺针对特定的资助计划）。
我有两个代表这些表的Javabean对象，我认为它们被称为DTO？无论如何......
现在在我的jsp视图中（用于编辑或插入承诺），我不希望用户看到或必须输入程序的主键，而是宁愿他们使用显示的选择下拉菜单已解析的程序名称，其中 fk id 作为选择选项值。
我的问题是： 我是否应该在请求中传递两个属性 - “commitment”，它代表该特定承诺的数据库中的单行记录（如果编辑），以及 programList 我迭代到的可用程序列表显示在下拉??
或者我应该修改我的承诺 DTO 并使其具有一个可以存储可用程序列表（作为程序 DTO）的属性，以便我只需要在请求中传递 commitment DTO归因于我的观点？
I have two database tables.
One table stores data for a commitment that a supervisor is responsible for.
The other is a lookup table of available programs. The program primary key is a foreign key in the commitment table (A commitment is against a particular funded program).
I have two Javabean objects that represent these tables, I think they are called DTO?? Anyways....
Now in my jsp view (for editing or inserting a commitment), I don't want users to see or have to enter the primary key to the program, but instead would rather they use a select pull down that shows the resolved program name with the fk id as the select option value.
My question is:
Should I be passing two attributes in the request - 'commitment' which represents the single row record in the db of that specific commitment (if editing) and the programList a list of available prgrams that I iterate over to display in a pull down??
Or should I modify my commitment DTO and make it have an attribute that can store a list of available programs (as program DTO's) so that then I'd only need to pass in the commitment DTO in a request attribute to my view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的第一种方法是更加自我记录。承诺与特定计划相关，而不是与多个计划相关。因此，在
承诺中包含List会让其他人感到困惑（当你一年后回顾时，也会让自己感到困惑）。也就是说，如果
List是应用程序范围的（阅读：每个用户/会话始终是相同的列表），我只需将其放在应用程序范围而不是请求范围中。Your first approach is more self-documenting. A commitment is tied to a specific program, not to multiple programs. Having a
List<Program>inCommitmentis therefore confusing to others (and also to yourself when you look back one year later).That said, if the
List<Program>is application-wide (read: it's always the same list for every user/session), I'd just put it in the application scope rather than the request scope.