我必须将一个较小的Windows窗体应用程序（产品配置器）移植到一个asp.net应用程序，该应用程序将在大公司的网站上使用，需求应该适中，因为它适用于专门的产品线。
我无权访问数据库，并且使用XML是他们的Web开发人员的要求。
大约有30种不同的产品，xml文件中存储了大约300种不同的可能配置，以及导致产品推荐的链接问题/答案。还有一些生产选择。该应用程序有6种语言版本。
如果您可以这样调用它，您将如何解决'数据访问'层？我想到将xml文件读取/反序列化到它们的对象中并将它们存储在asp.net的缓存中（如果它们不存在），然后在后续请求中从缓存中读取。但这意味着所有物体都会在白天和晚上都存在于记忆中。
这甚至是必要的，还是聪明的，性能明智的？正如我之前所说，应用程序并不是那么大，xml文件并不大。我是否可以创建一些Repository类，只要请求对象就读取xml文件（即'Product Details'或'Next question'）并以这种方式返回，并降低内存消耗？
答案 0 :(得分：1)
整个方法似乎都坚持使用单一服务器。首先考虑一下这是否合适，因为你提到了“大公司的网站”，这为我设置了一个红旗。如果您需要扩展站点，最终将拥有多个服务器，这会阻止考虑使用简单的本地文件。
如果您不得不使用它，请分析哪些数据更适合保留在缓存中（不经常更改，其存在时间长，不同时间请求相同的信息）。尝试将缓存的内容与非缓存分开，这将减少更动态文件中的信息量。如果您需要大量信息，请考虑使用适合您域名的文件拆分文件。
答案 1 :(得分：0)
我尽可能使用Cache。我在第一次请求时缓存对象。如果内存有任何问题，我会设置过期策略。无论是否存在，当内存不足时，框架无论如何都会卸载缓存。
由于它是每个应用程序而不是每个用户，因此有它是有意义的，特别是如果相对足迹很小。
如果以后必须扩展到多个服务器，则可以通过网络访问同一文件或修改DA层以通过任何其他方式（服务，数据库等）检索数据。缓存代码将保持不变，性能几乎不受影响。
如果设置依赖项，对象将始终保持最新状态。
我是为了它。
答案 2 :(得分：0)
使用缓存，并按照其他人的建议设置适当的过期策略是一种合理的方法。我建议您使用LINQ to XML作为数据访问代码的基础，因为它比传统的查询XML方法更容易使用。你可以找到一个体面的介绍here。