通过集合访问数据库
我有一个 3 层应用程序，我需要获取数据库结果并填充 UI。 我有一个处理消息的 MessagesCollection 类。 我从数据库加载我的用户。在实例化用户时（即 new User()），将执行 MessageCollection Messages = new MessageCollection(this)。消息收集接受用户作为参数。
User user = user.LoadUser("bob");
我想收到鲍勃的消息。
user.Messages.GetUnreadMessages();
GetUnreadMessages 调用我的业务数据提供程序，该提供程序又调用数据访问层。业务数据提供者返回列表。
我的问题是 - 我不确定这里的最佳实践是什么 - 如果我在 MessagesCollection 类内的数组中有一个消息集合，我可以实现 ICollection 以提供 GetEnumerator() 和遍历消息的能力。但是，如果消息发生变化并且用户加载了旧消息，会发生什么情况？
那么大的消息集合呢？如果我的用户有 10,000 条未读消息怎么办？我认为访问数据库并返回 10,000 个 Message 对象效率不高。
I have an 3 tiered application where I need to get database results and populated the UI.
I have a MessagesCollection class that deals with messages.
I load my user from the database. On the instantiation of a user (ie. new User()), a MessageCollection Messages = new MessageCollection(this) is performed. Message collection accepts a user as a parameter.
User user = user.LoadUser("bob");
I want to get the messages for Bob.
user.Messages.GetUnreadMessages();
GetUnreadMessages calls my Business Data provider which in turn calls the data access layer. The Business data provider returns List.
My question is - I am not sure what the best practice is here - If I have a collection of messages in an array inside the MessagesCollection class, I could implement ICollection to provide GetEnumerator() and ability to traverse the messages. But what happens if the messages change and the the user has old messages loaded?
What about big message collections? What if my user had 10,000 unread messages? I don't think accessing the database and returning 10,000 Message objects would be efficient.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来，如果您在用户之后发出单独的调用来加载消息，那么您将进行 2 次往返数据库的操作。如果可能的话，我会考虑进行一次旅行并在一次旅行中向用户加载消息。对于大型数据集，您可能需要考虑某种分页机制。用户不可能在单个视图中理解所有消息，因此最好一次显示一页。
该集合将能够毫无问题地跟踪内部更改（事件或其他）。您可以使用某些自定义事件或类似 INotifyPropertyChanged 接口的方式公开对实体的更改。
It appears that if you place a separate call to load the messages after the user then you are taking 2 round trips to the DB. If possible, I would consider making a single trip and loading the User with Messages in a single trip. In terms of large sets of data, you may want to consider some kind of paging mechanism. It would be impossible for the user to comprehend all the messages in a single view, therefore displaying them a page at a time would be preferable.
The collection will be able to track changes internally no problem(events or otherwise). You can expose the changes to your entity either using some custom event or something like the INotifyPropertyChanged interface.