IsChanged 功能应该在哪里处理？
我正在内部争论应该在哪里处理数据更改检查，但无法决定最有意义的做法：
- 在 GUI 中处理 IsChanged - 这需要在页面加载和发布数据之间保留数据可能会产生大量带宽/页面传送开销。这在 win 表单应用程序中并不是那么糟糕，但在网站中，这可能会对带宽成本产生重大的财务影响。
- 在 DAL 中处理它 - 这需要多次调用数据库以检查在保存数据之前是否有任何数据已更改。这可能意味着对数据库进行额外的不必要的调用，可能会因不必要的数据库查询而导致可伸缩性问题。
- 在 Save() 存储过程中处理它 - 这可能需要存储过程对表进行额外的不必要的调用来进行检查，但会保存从 DAL 到数据库的额外调用。这可能比让 DAL 处理它更好地扩展，但我的直觉告诉我这可以做得更好。
- 在触发器中处理它 - 这需要使用触发器（我在情感上反对，除非绝对必要，否则我倾向于避免触发器）。
- 根本不处理 IsChanged 功能 - 不仅处理“LastUpdated”日期变得困难，而且将不必要的数据保存到数据库本身对于可伸缩性来说似乎是一种不好的做法。
因此，每种方法都有其缺点，我不知道哪种方法是最好的。有没有人有任何更可扩展的想法来处理数据持久性，以查看是否有任何变化的特定目的？
架构：SQL Server 2005、ASP.NET MVC、IIS7、针对非特定全球受众的高可扩展性要求。
I'm having an internal debate about where I should handle checking for changes to data and can't decide on the practice that makes the most sense:
- Handling IsChanged in the GUI - This requires persistence of data between page load and posting of data which is potentially a lot of bandwidth/page delivery overhead. This isn't so bad in a win forms application, but in a website, this could start having a major financial impact for bandwidth costs.
- Handling it in the DAL - This requires multiple calls to the database to check if any data has changed prior to saving it. This potentially means an extra needless call to the database potentially causing scalability issues by needless database queries.
- Handling it in a Save() stored proc - This would require the stored proc to potentially make an extra needless call to the table to check, but would save the extra call from the DAL to the database. This could potentially scale better than having the DAL handle it, but my gut says this can be done better.
- Handling it in a trigger - This would require using a trigger (which I'm emotionally averse to, I tend to avoid triggers except where absolutely necessary).
- Don't handle IsChanged functionality at all - It not only becomes hard to handle the "LastUpdated" date, but saving data unnecessarily to the database seems like a bad practice for scalability in itself.
So each approach has its drawbacks and I'm at a loss as to which is the best of this bad bunch. Does anyone have any more scalable ideas for handling data persistence for the specific purpose of seeing if anything has changed?
Architecture: SQL Server 2005, ASP.NET MVC, IIS7, High scalability requirements for non-specific global audience.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好的，这是另一个解决方案 - 我没有考虑所有的影响，但我认为它可以工作：
考虑一下 GetHashCode() 比较功能：
在页面加载时，您计算页面数据的哈希码。如果您愿意，可以将哈希码存储在页面数据或视图状态/会话中。
在数据发布（回发）时，您计算发布的数据的哈希代码并将其与原始哈希进行比较。如果不同，则用户更改了某些内容，您可以将其保存回数据库。
Okay, here's another solution - I've not thought through all the repercussions, but it could work I think:
Think about the GetHashCode() comparison functionality:
At page load time, you calculate the hash code for your page data. You store the hashcode in the page data or viewstate/session if that's what you prefer.
At data post (postback) you calculate the hash code of the data that was posted and compare it to the original hash. If it's different, the user changed something and you can save it back to the database.
我在 DAL 中处理它 - 它包含原始值，因此无需访问数据库。
I handle it in the DAL - it has the original values in it so no need to go to the database.
对于系统中的每个实体，引入额外的版本字段。通过此字段，您将能够检查数据库级别的更改。
由于您有一个 Web 应用程序，并且通常可扩展性对于 Web 应用程序很重要，因此我建议您避免 UI 级别的 IsChanged 逻辑。 LastUpdated 日期可以在保存操作期间在数据库级别设置。
For each entity in your system introduce additional Version field. With this field you will be able to check for changes at the database level.
Since you have a web application and usually scalability matters for web application, I would suggest you to avoid IsChanged logic at the UI level. LastUpdated date can be set at the database level during Save operation.