我正在设计我的第一个N层架构。 Windows Azure的许多细节对我来说仍然是模糊的，所以我希望得到一些解释/建议。
到目前为止，我计划的架构如下。在客户端是一个Windows应用商店应用程序。在服务器端是Azure工作者角色和数据库。 Windows应用商店应用通过服务总线队列与工作者角色进行通信工作者角色通过实体框架代码优先与数据库进行通信。
当在客户端应用程序中打开特定屏幕时（即“会话”开始时），工作者角色通过实体框架代码优先查询数据库以填充屏幕。 worker角色将数据作为域对象获取，然后以DTO的形式返回到客户端应用程序。
用户完成客户端应用程序中的数据修改后，他/她单击一个按钮，将更改发送回工作者角色。这是“会话”结束的时候。那时，我需要在worker-role中使用一种方法来检查从客户端应用程序发回的修改数据，以确定哪些值已更改。这样做需要将更改的数据与其原始值进行比较。我的问题是：这些原始值可以/应该来自何处？
以下两种方法中的哪一种是可行和/或推荐的？
答案 0 :(得分：1)
您可以将退回的DTO存储在cache中：缓存速度更快但尺寸有限，因此您必须考虑您的商品可能会超出估计的生命周期或被逐出，在这两个不幸的事件中，您最终会查询数据库。 或者，您可以将项目存储在storage中：它可能仍然比查询数据库更快，并且在您的设计中更舒适，此处放置的物品是耐用的，没有过期或驱逐的风险，但您承担了清理的负担对你自己它也更昂贵：存储写入/读取操作成本，而写入/读取缓存是“免费”。
我无法发表自己在某处存储EF对象实例的可能性和机会。由于我的经验，我更愿意收集客户的意图，将返回的DTO与客户回来的DTO进行比较，但这只是我的看法。
您是否知道缓存中项目的预期生命周期，因为您设计了客户端 - 服务交互？高信心和短时间有利于缓存。您是否能够预见到预期生命周期内最大并发客户端服务交互次数？它是否适合您可以应用于设计的缓存大小？
我通常在缓存和存储之间进行选择，或者将两者结合起来：缓存和存储作为后备。查询db作为最后一个选项。
它会与您的情景产生共鸣吗？