Asp.net mvc 应用程序服务层作为静态类

在我的ASP.NET MVC应用程序中，我有一个包含所有业务逻辑/服务层的项目。此项目与位于单独项目中的我的数据库（实体框架）交互

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

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

然后，服务层执行所有必需的逻辑，然后通过

数据库层中的存储库创建用户

    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

字段也是静态的，所以我经常遇到的一个明显问题是，从多个DataContext检索同一对象会导致更新/删除的奇怪行为

---

我知道，如果我像在应用程序生命周期中一样使用静态成员/类，这是意料之中的，但是有没有办法将服务层用作

ServiceLayer.Accounts.Method（）

而不必创建一个非静态类，该类需要在使用它的任何地方进行实例化，并且不会因为多个datacontext实例而遇到CRUD问题？

我不知道您为什么如此坚决反对使用实例。除了您现在拥有的代码不必要地复杂之外，使用静态类型还使单元测试变得更加困难。静态类型类似于无法模拟/替换的单例。在我看来，您真正的问题可能是，“我如何管理我的服务层实例？”通常，您通过每个Web请求有一个实例来实现这一点。在ASP.NET MVC应用程序中，您可以[PDF]

您的方法确实不是推荐的方法。就个人而言，我决不会允许我的团队采用这种方式。缺点：

正如您所经历的，主要的线程问题并不容易解决

你根本无法很容易地测试它

对数据访问的不切实际的抽象

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

---

无论如何，您只需将存储库实例化作为基本服务类的一部分。没有理由说它必须是“到处都是静态或实例调用”。基类中应该有有限的实例实例化代码。

您需要以谨慎的方式处理objectcontext的作用域，比如执行

除此之外，我确实认为您应该重新考虑做任何静态的事情，正如womp所说的，您得到了非常高的耦合性，并且使测试变得非常困难，并且您可以通过使用IOC容器在管理依赖关系图方面获得很多帮助

---

我可以这样说，我之前做过类似的事情：）

单例（以及所描述的静态类）是邪恶的，应该不惜一切代价避免，尤其是在Web应用程序中。

我不同意这一点，当静态时，助手方法是理想的。事实上，一些最佳助手方法对于web使用是静态的。请求、Server.MapPath、文件/目录等。“事实上，一些最佳助手方法是静态的”您对“最佳”的概念是什么？还想补充一点，在控制器和服务之间使用静态类时，我遇到了升级到MSDTC的问题