在 ASP.NET 向导控件中管理多对多关系
假设我有一个具有很多属性的实体。在输入表单中，我决定实现一个向导控件，以便我可以通过几个步骤收集有关该实体的信息。问题是我需要收集已建模的具有多对多关系的信息。
我计划使用 telerik gridview 来管理它（添加/编辑/删除），问题是我在哪里存储该数据，因为插入表单中的实体尚未在数据库上创建。好的，所以我可以将所有这些信息存储在驻留在视图状态中的临时列表中，等待最终提交，将所有信息转储到数据库中，但是我收集文件的步骤之一......现在将文件存储在视图状态中已经结束问题的答案，与将它们存储在会话中相同...
我一直在考虑以用户必须首先提交一些信息（例如前 3 个步骤）的方式实现，将数据提交到创建父实体的数据库然后开始插入所有子实体...但这会变得很奇怪，因为它很混乱，因为在第一步中您没有将数据保存到数据库，而在接下来的步骤中您直接提交...
任何人对此有任何想法？
谢谢
Say I have this entity with a lot of attributes. In the input form I have decided to implement a wizard control so I can collect information about this entity in several steps. The problem is that I need to collect information that has been modeled has many to many relationships.
I am planning to use a telerik gridview to manage this (add/edit/delete), the problem is where do I store that data since the entity in a insert form is not created on the database yet. OK so I can store all that info in temporary lists residing in the viewstate, waiting for the final submit where I dump all that in the DB, but one of the steps I am collecting files...now storing files in the viewstate is out of the question, same as as storing them in the session...
I have been thinking of implementing in a way that the user has to submit some info first (say first 3 steps), commit the data to the database creating the parent entity and then start inserting all the childs entities...but this will get weird as it's confusing since on the first steps you not saving the data to the DB and on the next ones you are commiting directly...
Anyone has any thoughts on this?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
考虑在数据库中创建一个“保存”表，您可以在其中存储向导数据，而不是将其存储在 ViewState 中。该表可以有一列用于存储用户的SessionID，这样您就可以知道哪些记录属于哪些用户。用户完成向导步骤后，您可以检索所有数据并将其提交到最终表。
您可能还想创建一个作业，通过删除超过 n 小时的记录来定期清理“持有”表，这样就不会累积孤立记录。
Consider creating a "holding" table in your database where you can store your wizards data, rather than storing it in ViewState. The table could have a column for the user's SessionID, so you can know what records belong to what users. Once the users has completed the wizard steps, you can retrieve all of the data and commit it to the final table(s).
You may also want to create a job that regularly cleans your "holding" table by removing records that are more than n hours old, so you don't accumulate orphaned records.