级联组合框和实体结构
在我们的 ASP.Net 项目中，我们有一个包含 3 个（甚至更多）级联组合框的视图， 问题是我们应该如何设计我们的（基于 NHibernate 的）实体，因为组合框之间的关系仅与构建视图相关，并且 3 种实体类型的整个 catesian 乘积约为 2000 个实体。
所以问题实际上是：
我们是否应该将实体设计为层次结构，即使集合没有额外的业务价值（从而使它们成为任何其他场景的开销）
数据应该作为平面行发送吗？保持实体更加“干净”，但需要额外的 在视图端编码
与后续请求分开（例如，仅在选择组合 A 后，才从服务器获取组合 B 的数据）？使整个过程可能更高效，但以性能和缓存为代价？
有什么想法吗？
In our ASP.Net project we've got a view with 3 (or even more) cascaded combo-boxes,
The question is how should we design our (NHibernate-based) entities given that the relationship between the combo-boxes is relevant only for the sake of building the view, and given that the entire catesian product of the 3 entity types is around 2000 entities.
So the questions are actually:
Should we design the entities as a heirarchy even though the collections has no additional business value (thus making them an overhead for any other scenario)
Should the data be sent as flat rows? keeping the entities more "clean", but requires additional
coding on the view's sideSeperate to consequent requests (e.g only after combo A is selected, combo B's data is fetched from the server)? making the entire process maybe more efficient but at the cost of performance and perhaps caching?
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，您不应该通过一个预期的 UI 来设计您的模型（实体）。今天是 3 个下拉列表，明天它可以在一周内自动完成和一些新的奇特的“哇”组件，但您的模型应该保持稳定 - 它描述实体之间的实际业务关系，而不是您当前的 UI。由此看来，我认为很明显你应该使用 2 和 3 的组合。
First of all, you should not design your model (entities) by one intended UI. Today is it 3 dropdown, tommorow it can be autocomplete nad in a week some new fancy "wow" component, but your model should stay solid - it describes actual, business relations between entities, not your current UI. From this, i think it is quite obvious that you should use combination of 2 and 3.