1

我有一个项目，其中每个控制器都需要 CurrentSettings 和 CurrentUser 类。我使用静态类来获取这些，但有人建议使用 Wrapper 类，因为使用静态类不好。

我的问题是，在每个控制器中我都必须这样做：

    #region Fields

    private readonly ProfileService service;
    private readonly Profile currentUser;
    private readonly Settings currentSettings;

    #endregion

    #region Constructors

    public _UsersController()
    {
        var companyWrapper = new CompanyWrapper();
        var profileWrapper = new ProfileWrapper();
        var settingsWrapper = new SettingsWrapper();

        var companyId = companyWrapper.CurrentCompanyId();

        service = new ProfileService(companyId);
        currentUser = profileWrapper.CurrentUser();
        currentSettings = settingsWrapper.CurrentSiteSettings();
    }

    #endregion

我认为这是一场噩梦。当然有更好的清洁方法来做到这一点。如果有人能指出我正确的方向，我将不胜感激。

PS：我对这个项目中的几乎所有东西都使用存储库/服务设计模式。

干杯，/r3plica

4

3 回答 3

3

您必须了解为什么要进行更改。不要仅仅因为有人说它更好就做出改变。这都是关于上下文的。您想通过这种变化实现什么目标？

将静态类隐藏在包装器后面的一个重要原因是让您的代码更易于测试。当您希望能够测试类时，静态方法通常（但不总是）会妨碍您。在这种情况下，让您的控制器依赖于为您提供用户上下文信息的静态类肯定会妨碍对您的控制器进行单元测试，因为此类提供的信息将基于诸如HttpContext会话或会话之类的内容。HTTP 上下文在您的单元测试套件中不可用，您应该避免依赖它，因为这会使您的单元测试变得脆弱且难以维护。

因此，与其让控制器依赖于该静态类，不如让它们依赖于接口，例如IUserContext. 在您的 Web 应用程序中，您可以有一个将调用转发到静态类的实现，但在您的单元测试中，您应该使用该接口的假实现。这可以防止单元测试使用 ASP.NET 特定的类，并允许您为控制器提供假用户以进行测试。

而且，即使您没有对代码进行单元测试（无论如何您可能应该做的事情），依赖于抽象可以使您的应用程序更加灵活和可维护，但是您必须根据具体情况来决定.

于 2013-11-05T13:35:28.390 回答
2

您是否考虑过使用继承来允许您在不重复相同代码的情况下重用功能？

例如，您可以创建一个在默认构造函数中实例化所需类的基类。这样，您就可以从子类访问它们而无需重复代码。

public class UsersController : ControllerBase
{
于 2013-11-05T13:17:32.620 回答
0

您可以创建具有这些字段的自定义控制器。

于 2013-11-05T13:20:56.837 回答