静态类最佳实践

时间:2013-11-05 13:13:28

标签: c# design-patterns static

我有一个项目,每个控制器都需要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

3 个答案:

答案 0 :(得分:2)

您是否考虑过使用继承来重用功能而不重复相同的代码?

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

public class UsersController : ControllerBase
{

答案 1 :(得分:2)

您必须了解进行更改的原因。不要只是因为有人说它更好而做出改变。这完全取决于背景。你想通过这种改变实现什么目标?

将静态类隐藏在包装器后面的一个重要原因是允许您的代码更易于测试。当您希望能够测试类时,静态方法通常(但并非总是)在路上。在这种情况下,让控制器依赖于为您提供用户上下文信息的静态类肯定会对控制器进行单元测试,因为此类提供的信息将基于HttpContext或会话。您的单元测试套件中没有HTTP上下文,您应该防止这取决于此,因为这会使您的单元测试变得脆弱且难以维护。

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

尽管如此,即使你没有对你的代码进行单元测试(你可能应该做什么),取决于抽象可以使你的应用程序更加灵活和可维护,但是你必须在个案基础。

答案 2 :(得分:0)

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