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

在我的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字段也是静态的，所以我一直遇到的明显问题是从多个数据上下文中检索同一对象，从而导致更新/删除的奇怪行为。

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

来源

2010-02-17 Omar

“事实上，一些最好的帮手方法是静态的”你最好的概念是什么？ – 2010-11-09 02:58:02

您的方法实际上不是推荐的方法。就我个人而言，我绝不会允许我的团队使用这种方法。缺点：

主要线程问题，您所遇到，这不是简单的解决
您不能对此进行测试很容易的。
的数据访问

的最大原因创建库的情况下，不切实际的抽象是这样，如果你需要，你可以注入的依赖关系。最着名的论点是单元测试，因此您可以模拟依赖关系，但是我已经构建了一些存储库，这些存储库的生产代码中有接口依赖关系。

您应该简单地将您的存储库实例化作为您的基本服务类的一部分。没有任何理由，它必须是“静态的或实例调用无处不在”。基类中应该有有限的实例实例化代码。

来源

2010-02-17 19:46:06 womp

还想补充一点，当我在控制器和服务之间使用静态类时遇到了升级到MSDTC的问题 – DevDave 2012-02-21 13:20:46

我不知道你为什么如此死定了使用实例。除了现在的代码不必要的复杂之外，使用静态类型还会使单元测试更加困难。静态类型就像一个你不能模拟/替换的单例。在我看来，你真正的问题可能是，“我如何终身管理我的服务层实例？”通常情况下，您通过为每个Web请求创建一个实例来完成此操作在ASP.NET MVC应用程序中，您可以new up a DI container via a ControllerFactory, and handle all of this. [PDF]

来源

2010-02-17 19:45:07

您需要处理您的ObjectContext的范围一字一板地，像这样做一个Unit Of Work pattern

除此之外，我认为你应该重新考虑做的一切静态，作为womp说你得到很高的耦合，以及使测试变得非常困难，并且您可以通过使用IOC容器来管理依赖图的很多帮助。

我可以这样说，已经烧毁自己做这样的事以前:)

来源

2010-02-17 20:03:05 Luhmann

-3

单身（和描述静态类）是邪恶的，应在特别是在Web应用程序一切代价避免。

来源

2010-02-17 20:09:50 Ahmad

我不同意这一点，当静态方法时Helper方法是理想的。事实上，一些最好的辅助方法对于Web的使用是静态的。请求，Server.MapPath，文件/目录等... – Mike 2010-05-20 20:55:07

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

回答

相关问题