在 MVC 中的应用程序级别持久保存数据库存储的查找数据的最佳实践

发布于 2025-01-08 00:09:52 字数 648 浏览 0 评论 0原文

努力通过 MVC+EF 并尝试专注于以正确的方式做事。现在我正在寻找向表单添加一个下拉菜单，但我想避免每次加载页面时都访问数据库，因此我想将数据存储在应用程序级别。我认为创建应用程序级别变量并不是最好的方法。我读过有关使用缓存和静态实用函数的内容，但令人惊讶的是，没有什么听起来非常明确。（静态类不利于单元测试，缓存不好

所以我有两个我很好奇的场景，我不确定两者之间的方法是否会有所不同。1

）基本查找，比方说五十个州。小，明确，永远不会改变。在应用程序启动时加载。（不是寻找硬编码的解决方案，而是从数据库中检索。）

2）很少会更改且仅通过类似管理的屏幕进行的查找。比方说，销售您的产品的城市/商店。所以数据会被存储在模型中，但除非有人通过应用程序进行更改，否则将是相对静态的。因此，每次我需要填充下拉列表/列表框时，都不希望访问数据库。

看起来像是基本的东西，但它基本上与这个从未得到解答的主题相同：

在 MVC 应用程序中使用静态 EF 对象上下文是否可以实现更好的性能？

感谢任何帮助。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

够钟 2025-01-15 00:09:52

我将分几个部分回答你的问题。首先，在 MVC 中使用静态变量或缓存模式本质上是不好的吗？答案是否定的。只要你的架构支持它们就可以了。只需将缓存放在正确的位置并进行可测试性设计，我将在稍后解释。

第二部分是存储此类持久数据的“正确”方法，这样您就不必往返数据库来填充常见的 UI 项目。为此，我不建议存储 EF 对象。我将创建您缓存的 POCO 对象（视图模型或类似对象）。因此，在 50 个州的示例中，您可能会遇到这样的情况：

public class State
{
    public string Abbreviation { get; set; }

    public string Name { get; set; }
}

然后您将执行类似的操作来创建缓存列表：

List<State> states = Context.StateData.Select(s => new State { Abbreviation = s.Abbreviation, Name = s.Name}).ToList();

最后，无论您的缓存解决方案是什么，它都应该实现一个接口，以便您可以模拟该缓存方法进行测试。

要做到这一点而不遇到循环引用或使用反射，您将需要至少 3 个程序集：

您的 MVC 应用程序
用于定义 POCO 对象和接口的类库
类库确实执行数据访问和缓存（如果这样可以更容易维护和/或测试，这显然可以分为 2 个库）

这样，您就可以在 MVC 代码中使用类似的内容：

ICache myCache = CacheFactory.CreateCache();
List<State> states = myCache.ListStates();
// populate your view model with states

ICache 和 State 所在的位置一个库，而 ICache 的实际实现在另一个库中。

这就是我为我的标准架构所做的：将与数据访问无关的 POCO 对象和接口拆分为与我的 MVC 应用程序分开的数据访问的单独库。

I will address you question in a few parts. First off, is it inherently bad to use static variables or caching patterns in MVC. The answer is simply no. As long as your architecture supports them it is OK. Just put your cache in the right place and design for testability as I will explain later.

The second part is what is the "right" way to have this type of persisted data stored so you don't have to make round trips to the DB to populate common UI items. For this, I don't recommend storing EF objects. I would create POCO objects (View models or similar) that you cache. So in the example of your 50 states you might have something like this:

public class State
{
    public string Abbreviation { get; set; }

    public string Name { get; set; }
}

Then you would do something like this to create your cached list:

List<State> states = Context.StateData.Select(s => new State { Abbreviation = s.Abbreviation, Name = s.Name}).ToList();

Finally, whatever your caching solution is, it should implement an interface so you can mock that caching method for testing.

To do this without running into circular references or using reflection, you will need at least 3 assemblies:

Your MVC application
A class library to define your POCO objects and interfaces
A class library do perform your data access and caching (this can obviously be split into 2 libraries if that makes it easier to maintain and/or test)

That way you could have something like this in your MVC code:

ICache myCache = CacheFactory.CreateCache();
List<State> states = myCache.ListStates();
// populate your view model with states

Where ICache and State are in one library and your actual implementation of ICache is in another.

This is what I do for my standard architecture: splitting POCO objects and interfacees which are data access agnostic into a separate library from data access which is the separate from my MVC app.

回复收藏 0 原文