在工作角色中缓存域对象

Question

我正在设计我的第一个 N 层架构。 Windows Azure 的许多细节对我来说仍然是模糊的，所以我希望得到一些解释/建议。

到目前为止，我已将架构规划如下。客户端是一个 Windows 应用商店应用程序。服务器端是 Azure 辅助角色和数据库。 Windows 应用商店应用通过服务总线队列与辅助角色通信辅助角色通过实体框架代码优先与数据库通信。

当在客户端应用程序中打开特定屏幕时（即“会话”开始时），辅助角色首先通过实体框架代码查询数据库以填充屏幕。辅助角色获取数据作为域对象，然后作为 DTO 返回到客户端应用程序。

用户在客户端应用程序中完成修改数据后，他/她单击一个按钮，将更改发送回辅助角色。这是“会话”结束的时候。那时，我需要一种方法来检查从客户端应用程序返回的修改后的数据，以确定哪些值已更改。这样做需要将更改的数据与其原始值进行比较。我的问题是：这些原始值可以/应该从哪里来？

以下两种方法中哪一种是可行和/或推荐的？

1. 域对象（对象实例）一直可用，直到会话结束。这样我就不需要再次运行原始数据库查询。 Azure 中的哪些机制允许这样做？
2. 或者，当会话结束时，辅助角色会重新查询数据库。

Answer 1

您可以将返回的 DTO 存储在 cache 中：缓存速度更快，但大小有限，因此您必须考虑您的项目可能会超过估计的生命周期或被驱逐，在这两种不幸的事件中，您最终都会查询D b。 或者，您可以将这些项目存储在storage：它可能仍然比查询数据库更快并且适合您的设计，放置在这里的项目是耐用的，没有过期或驱逐的风险，但您自己承担清理的负担.它也更昂贵：存储写入/读取操作成本，而写入/读取到缓存是“免费的”。

我无法就在某处存储 EF 对象实例的可能性和机会发表意见。由于我的经验，我更喜欢收集客户的意图，将返回的 DTO 与从客户返回的 DTO 进行比较，但这只是我的意见。

您是否知道缓存中项目的预期生命周期，因为您是如何设计客户端-服务交互的？高置信度和短时间有利于缓存。您是否能够预见在预期生命周期内并发客户端服务交互的最大数量？它是否适合您可以应用于您的设计的缓存大小？

我通常在缓存和存储之间进行选择，或者将两者结合起来：缓存和存储作为后备。将查询数据库作为最后一个选项。

它是否与您的场景产生共鸣？