应用程序服务层作为静态类

Question

在我的ASP.NET MVC应用程序中,我有一个包含所有业务逻辑/服务层的项目.该项目与我的数据库(实体框架)进行交互,该数据库位于一个单独的项目中.

我希望能够轻松访问服务层,因此我在其中创建了静态类,以便可以轻松地引用它们.例如,如果我在我的控制器中,我需要创建一个新帐户:

 ServiceLayer.Accounts.CreateAccount(userName, passWord) //etc..

然后服务层执行所有必需的逻辑,然后通过存储库创建用户DatabaseLayer.

    private static AllRepos _Repos;
    private static AllRepos Repos { 
       get 
        { 
           if(_Repos == null)
              _Repos = new AllRepos();

           return _Repos
        }
    }

    public static void CreateAccount(string username, password)
    {
        string salt = GenerateSalt();
        Account newAccount = DatabaseLayer.Models.Account
              { 
              Name = username,
              Password = HashPassword(password, salt),
              Salt = salt
              };
        Repos.AddAccount(newAccount);      
    }

因为我不想在我的服务层中到处执行以下操作:

 AccountRepository Accounts = new DatabaseLayer.AccountRepository();

我为我的存储库创建了一个包装类,这样我只需要实例化一次就可以使用所有其他存储库.

 public class AllRepos
 {

    private AccountRepository _Accounts;

    public AccountRepository Accounts
    {
        get
        {
            if (_Accounts== null)
                _Accounts= new AccountRepository();

            return _Accounts;
        }
    }

    // the same is done for every other repository (currently have about 10+)
  }

这是在服务层的静态类中使用的.

因为我的所有服务层类都是静态的,并且该Repos字段也是静态的,所以我遇到的明显问题是从多个datacontexts中检索相同的对象,导致更新/删除的奇怪行为.

我理解,如果我使用静态成员/类,因为它们持续应用程序的生命周期,这是可以预期的,但是有一种方法可以使用服务层,ServiceLayer.Accounts.Method()而无需创建非静态类需要在使用它的任何地方实例化,并且由于多个datacontext实例而不会遇到CRUD问题？

Answer 1

你的方法实际上不是推荐的方法.就个人而言,我永远不会允许我的团队使用这种方法.缺点:

1. 正如您所遇到的那样,主要的线程问题并不容易解决
2. 你根本无法轻易测试.
3. 不切实际的数据访问抽象

创建存储库实例的最大原因是,如果需要,可以注入依赖项.对此最着名的论点是单元测试,因此您可以模拟依赖项,但我已经构建了许多存储库,这些存储库具有在生产代码中发生变化的接口依赖性.

您应该简单地将存储库实例化作为基本服务类的一部分.没有必要将它"静态或实例调用到处".基类中应该有有限的实例实例化代码.

Answer 2

我不确定为什么你这么反对使用实例.除了您现在拥有的代码不必要的复杂之外,使用静态类型也会使单元测试变得更加困难.静态类型就像一个你无法模拟/替换的单例.在我看来,你真正的问题可能是,"我如何终身管理我的服务层实例？" 通常,您通过为每个Web请求设置一个实例来执行此操作.在ASP.NET MVC应用程序中,您可以通过ControllerFactory新建DI容器,并处理所有这些.[PDF]