0

我正在使用 Entity Framework 进行我的第二个项目，我想阅读一些关于代码是否低于其良好编码实践的意见。

我提出的架构是这样的：

在此处输入图像描述

因此，网站调用业务逻辑，在那里评估业务规则。然后它调用 DALFacade，只是它对于上层是不可见的，无论我们是访问 db2 还是 sql server。

EF DAL，它负责与数据库对话，CODE FIRST Approach。实体类库是带有 poco 类的项目。实用程序是不言自明的，我可能会放一些代码，比如从活动目录中读取属性。

所以这是我的代码，我尽可能地简化了它

一页：

protected void BtnSubmitRequestClick(object sender, EventArgs e)
    {
        var ecoBonusWorkflow = new EcoBonusWorkflow
                                   {
                                       IsOnHold = true
                                   };

        BusinessLogic.EcoBonusRequestSave(ecoBonusWorkflow);
    }

商业逻辑：

public static class BusinessLogic
    {
        public static void EcoBonusRequestSave(EcoBonusWorkflow ecoBonusWorkflow)
        {
            if (true)
            {
                DalFacade.EcoBonusRequestSave(ecoBonusWorkflow);
            }
        }
    }

DAL外观：

 public static class DalFacade
    {
        private  static readonly UnitOfWork UnitOfWork = new UnitOfWork();

        public static void EcoBonusRequestSave(EcoBonusWorkflow ecoBonusWorkFlow)
        {
            UnitOfWork.EcoBonusWorkflowRepository.InsertEcoBonusWorkflow(ecoBonusWorkFlow);
        }
    }

然后在 EF Dal 类库中，我使用传统的 EF 4.1 代码优先方法。我还使用了存储库模式和工作单元。

欢迎任何意见

4

1 回答 1

2

包含“实用程序”对我来说似乎很奇怪。其他所有东西的名字都很好，并有一个非常具体的设置来说明它应该做什么，然后你就有了这个命名模糊的“实用程序”块。

这不是任何特定的编码标准，但我会尽可能避免将“实用程序”合并到您的顶级架构中。每个项目都有一些名为“helpers”或“utilities”的文件夹，它最终成为大量杂项代码的转储，这些代码似乎无法立即适用于其他任何地方。这正是技术债务和意大利面条代码开始的方式。

除非您是该项目的唯一开发人员，否则无论您呈现什么，它都可能最终发生，但我仍会避免使其合法化。

此外，在你的快速和肮脏中包含静态类让我感到震惊。除了静态代码会损害可测试性这一事实之外，Entity 框架不是线程安全的。以线程安全的方式使用它取决于您，因此，如果您有任何多线程或协同处理，您的 DALFacade 将随机抛出大量错误并令人头疼。

我也没有在您的设计中看到任何依赖注入的余地，这再次涉及代码的可测试性。

编辑：好的，这些不是 Stack 的让步，所以是时候介绍依赖注入的概念了。

基本上，任何时候你直接依赖其他东西，比如当你调用一个静态类时，你就是把这两个东西联系在一起了。如果不修改或更换另一部分，则一个部分不再是可更换的。这是一件坏事，因为它使重构和更改成为一个非常大的问题。相反，您想要做的是“松散耦合”这些依赖项，这样您就可以在不破坏所有内容的情况下更改部分。在 C#/.NET 中，您主要使用接口来执行此操作。

因此，与其拥有“DALFacade”并直接传递它，不如使用以下效果：

interface IDalFacade
{
    int DoAThing();

    bool DoAnotherThing();
}

class DalFacade : IDalFacade
{
    public int DoAThing()
    {
        return 0;
    }

    public bool DoAnotherThing()
    {
        return false;
    }
}

然后，您可以在您的业务逻辑中使用它，如下所示：

class BusinessLogic : IBusinessLogic
{
    public IDalFacade DalFacade { get; private set; }

    public BusinessLogic() : this(new DalFacade())
    {}

    public BusinessLogic(IDalFacade dalFacade)
    {
        this.DalFacade = dalFacade;
    }

    public void LogicTheThings()
    {
        this.DalFacade.DoAThing();
    }
}

现在，如果 DalFacade 完全被破坏，或者突然之间你需要其中两个来做不同的事情，现在都不再重要了。甚至，真的，如果一个 DalFacade 被传入。只要它履行 IDalFacade 合同，它就完全没问题。你仍然可以不带参数调用它（它只是假设一个特定的实现），但即使这样也不理想。理想情况下，您会希望使用依赖注入库，例如Ninject或StructureMap，这样您就可以更轻松地进行任何特定的更改。

这在尝试对代码进行单元测试时也很有用，因为正如我所说，您甚至不需要实际的 DalFacade 来做事。您可以简单地模拟出一些填充 IDalFacade 合同的东西（使用类似RhinoMocks的东西），然后您可以完全独立于项目中的其他任何东西来测试您的所有代码。

于 2012-05-07T16:07:07.160 回答