应该在哪里处理IsChanged功能？

Question

我正在讨论如何处理检查数据更改的内容，而无法决定最有意义的实践：

1. 在GUI中处理IsChanged - 这需要在页面加载和数据发布之间持久存储数据，这可能会带来很多带宽/页面传送开销。这在win表单应用程序中并不是那么糟糕，但在网站中，这可能会对带宽成本产生重大的财务影响。
2. 在DAL中处理它 - 这需要多次调用数据库，以便在保存之前检查是否有任何数据已更改。这可能意味着对数据库的额外不必要的调用可能会导致不必要的数据库查询导致可伸缩性问题。
3. 在Save（）存储过程中处理它 - 这将要求存储过程可能会对表进行额外的不必要调用以进行检查，但会将额外调用从DAL保存到数据库。这可能比DAL处理它更有可能扩展，但我的直觉说这可以做得更好。
4. 在触发器中处理它 - 这需要使用触发器（我在情绪上反对，我倾向于避免触发器，除非绝对必要）。
5. 根本不处理IsChanged功能 - 它不仅难以处理“LastUpdated”日期，而且将数据不必要地保存到数据库本身似乎是可扩展性的一种不好的做法。

所以每种方法都有它的缺点，我不知道哪一个是最糟糕的一堆。有没有人有更多可扩展的想法来处理数据持久性，以便查看是否有任何变化？

架构：针对非特定全球受众的SQL Server 2005，ASP.NET MVC，IIS7，高可扩展性要求。

Answer 1

我在DAL中处理它 - 它具有原始值，因此无需转到数据库。

Answer 2

好的，这是另一个解决方案 - 我没有考虑过所有的影响，但我认为它可行：

考虑一下GetHashCode（）比较功能：

在页面加载时，您计算页面数据的哈希码。如果您喜欢这样，则将哈希码存储在页面数据或视图状态/会话中。

在数据发布（回发）时，您计算已发布数据的哈希码，并将其与原始哈希值进行比较。如果它不同，则用户更改了某些内容，您可以将其保存回数据库。

• 赞成
  • 您不必将所有原始数据存储在页面加载中，这会减少带宽/页面传送开销。
  • 您不必让DAL多次调用数据库来确定某些内容是否已更改。
  • 只有在更改内容时才会在数据库中更新记录，从而保持正确的LastUpdated日期。
• 缺点
  • 您仍然需要将数据库中的任何原始数据加载到未存储在“viewstate”中的业务对象中，而该“业务对象”是将有效记录保存到数据库所必需的。
  • 更改一个字段将更改散列，但除非您从数据库中调用原始数据进行比较，否则您不知道哪个字段。另外，也许你不需要。如果您必须更新时间戳更改的任何字段，并且覆盖未针对所有密集目的而未更改的字段，则无效。
  • 你不能完全排除碰撞的可能性，但它们很少见。这归结为是否可以接受碰撞？
• 或/或
  • 如果将哈希值存储在会话中，那么可以节省带宽，但会增加服务器资源，因此在任何一种情况下都要考虑潜在的可伸缩性问题。
• 未知
  • 更新单个列的开销是否与更新记录中的多个/所有列的开销不同？我不知道性能开销是多少。

Answer 3

对于系统中的每个实体，请引入其他版本字段。使用此字段，您将能够检查数据库级别的更改。

由于您有一个Web应用程序，并且通常可伸缩性对Web应用程序很重要，我建议您在UI级别避免使用IsChanged逻辑。可以在保存操作期间在数据库级别设置LastUpdated日期。