1

我为我的网站做了一个设置页面。在这个页面上，用户会看到一堆他们可以操作的站点范围的设置。我这样做是为了当用户选择一个设置时，页面会自动运行一个 ajax 请求以将设置发送到数据库。我的问题是我如何做到这一点。

起初我只是调用了存储库。一次调用以取回数据，将其放入 ViewModel，然后将该 ViewModel 提供给 View，然后 ajax 控制器将设置发送回数据库。这种方式一开始似乎是最好的，尤其是对于单元测试而言，因为如果需要我可以传入一个虚假的存储库。然后让用户获取他们刚刚调用存储库的设置并传入他们想要的设置名称。

然后我有了一个绝妙的主意。我创建了一个名为 SiteWideSettings 的单例类，站点上的每个可能设置都是站点的属性。首次调用 SiteSettings 时，会加载所有设置。当在任何属性上调用 Set 时，它将调用存储库函数来发送设置。现在使用我的设置视图，我只是传入 SiteWideViewOptions.Current 并在 ajax 调用中更新已更改的属性。这对我有用，但是它不是非常可单元测试的，因为我不能真正将存储库传递给单例的构造函数，因为它的构造函数是私有的。我目前所拥有的工作正常，但我只是觉得它不是最好的解决方案，并且单元测试在这里实际上是不可能的。

我正在考虑以下之一，但不确定哪个是最好的。

  • 将 Repository 属性添加到 SiteWideSettings 类
  • 向 SiteWideSettings 类添加函数以传入存储库
  • 根本不使用单例，而是回到我有这个想法之前所做的事情

对此的任何评论将不胜感激。

笔记：我知道。我知道在这种情况下我做单元测试是错误的，因为我没有先写我的测试所以请不要为此责备我。我已经责备过自己，我的下一个任务我不会再这样做了承诺 ：）

4

1 回答 1

1

“然后我有了一个好主意。我创建了一个名为 SiteWideSettings 的单例类，然后……”

这听起来是个坏主意。让您的数据库对设置是真实的，而不是您现在需要保持最新的内存缓存。如果您需要 ORM 以提高性能，请让您的 ORM 进行缓存，否则您只会添加问题，特别是如果您现在尝试在多台服务器上运行您的网站。

如果您想简化控制器以减少“设置”和“拆卸”代码，请使用 IOC（例如 Autofac）并在每个控制器上注入您需要的任何依赖项（例如 DataContext 或存储库） -http请求基础。

您的操作方法现在更容易测试，因为您可以简单地实例化您的控制器（使用其构造函数手动注入依赖项），然后调用您的方法。

于 2012-05-13T21:53:26.460 回答